[Top] [All Lists]

Re: RFC: NAPI packet weighting patch

To: Leonid Grossman <leonid.grossman@xxxxxxxxxxxx>
Subject: Re: RFC: NAPI packet weighting patch
From: Andi Kleen <ak@xxxxxxx>
Date: Wed, 22 Jun 2005 19:05:49 +0200
Cc: "'Donald Becker'" <becker@xxxxxxxxx>, "'Andi Kleen'" <ak@xxxxxxx>, "'Rick Jones'" <rick.jones2@xxxxxx>, netdev@xxxxxxxxxxx, davem@xxxxxxxxxx
In-reply-to: <200506221623.j5MGNkxS001340@xxxxxxxxxxxxxxxxx>
References: <Pine.LNX.4.44.0506211642290.21812-100000@xxxxxxxxxxxxxxxxxx> <200506221623.j5MGNkxS001340@xxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Wed, Jun 22, 2005 at 09:23:41AM -0700, Leonid Grossman wrote:
> > 
> > See the comment above. We decide if a packet is multicast vs. 
> > unicast, IP vs. other at approximately 
> > interrupt/"rx_copybreak" time.  Very few NIC provide this 
> > info in status bits, so we end up looking at the packet 
> > header.  That read moves the previously known-uncached data 
> > (after all, it was just came in from a bus write) into the L1 
> > cache for the CPU handling the device.  Once it's there, the 
> > copy is almost free.
> What status bits a NIC has to provide, in order for the stack to avoid
> touching headers?

To avoid it completely is pretty hard - you would need to supply
nearly everything in the header.

But when you supply L2 protocol/ and unicast/broadcast/multicast information
and if the packet is destined to the localhost or not then the 
headers can be gotten with a prefetch early and then when 
the header is later processed then it might be with some luck
already in cache.

BTW quite a few modern NICs provide this information actually contrary
to what Donald stated (sometimes with restrictions like only
works without multicast), but it hasn't been widely used yet.


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