[Top] [All Lists]

Re: NAPI-ized tulip patch against 2.4.20-rc1

To: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Subject: Re: NAPI-ized tulip patch against 2.4.20-rc1
From: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Wed, 06 Nov 2002 13:30:56 -0800
Cc: "'netdev@xxxxxxxxxxx'" <netdev@xxxxxxxxxxx>
Organization: Candela Technologies
References: <> <> <> <>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910
Robert Olsson wrote:
Ben Greear writes:

I still doubt ;-)

With e1000 I played with various settings for RX-buffers rather recently when the 82544 increased the number of available buffers from 256 to 4096.

And I guess my test looks a bit like yours... Injecting an "overload" of packets. I found was 256 buffers was the optimum. Approximative of course.

It's possible that it is a particular issue with my NICs (Old Phobos 4-port). Phobos folks said the bridge chipset has errata that make it un-suitable for high speeds. And something about a memory divide-by-four error. It may be that the extra buffers help hide the hardware defects in some manner. I was, for instance, seeing cases where packets just dissappeared...and no error counters were being bumped.

With the latest kernel drivers, the 570tx NIC seems to have
trouble autonegotiating full-duplex again, so I have not been testing
with it lately (I think it uses the same bridge chipset anyway.)

I will try changing around those numbers again now that I have a baseline
to work from.

And as you saw for SMP with recycle it is easy to feed the recycled skb back to CPU were it was created/processed.

Yes, I can see how that would be useful on SMP, so there may be less gain for single-proc systems. I actually am pretty fuzzy on cache-line optimizations and the like...

Thanks, Ben

Ben Greear <greearb@xxxxxxxxxxxxxxx>       <Ben_Greear AT>
President of Candela Technologies Inc

<Prev in Thread] Current Thread [Next in Thread>