On Thu, 14 Sep 2000, Donald Becker wrote:
> No, because I know I sound like a broken record. <skip><skip>
;->
> What we measured is that the cache impact of allocating and initializing our
> (ever-larger) skbuffs is huge. So we pay some CPU time getting a new
> skbuff, and some more CPU time later reloading the cache with useful data.
>
> The skbuff is added to the end of the driver Rx buffer list, so the memory
> lines are out of the cache by the time we need them.
So is there a workable solution to this?
>
> The Rx ring should be able to hold at least
> (interrupt-latency * 100/1000Mbps) bits
> and
> (interrupt-latency * 100/1000Mbps)/(64 bytes/packet * 8 bits/byte) packets
>
cool. Assuming 64 bytes because it is minimal sized ethernet packet?
> The PCI drivers make some effort to always allocate the same size skbuff, so
> recycling skbuffs, or otherwise optimizing their allocation, is useful.
>
Good to hear this from you.
> The only significant advantage of interrupt mitigation is cache locality
> when allocating new skbuffs, and having an additional mechanism to drop
> packets under overwhelming load.
>
> The disadvantage of Rx interrupt mitigation is adding latency just where it
> might matter the most.
One of the things we need to measure still is the latency. The scheme
currently used with dynamically adjusting the mitigation parameters might
not affect latency much -- simply because the adjustement is based on the
load. We still have to prove this. The theory is:
Under a lot of congestion, you delay longer because the layers above
you are congested as gauged from a feedback; and under low congestion, you
should theoretically adjust all the way down to 1 interupt/packet. Under
heavy load, your latency is already screwed anyways because of large
backlog queue; this is regardless of mitigation.
> Remember that the hot ticket for old-IPX performance
> was taking an *extra* early interrupt for each Rx packet.
If i remember correctly some of the 3coms still give this 'mid-interupt',
no? It could useful to just say quickly read the header and make routing
decisions as in fast routing but not under heavy load.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:25 EST