netdev
[Top] [All Lists]

Re: RFC: NAPI packet weighting patch

To: "David S. Miller" <davem@xxxxxxxxxxxxx>
Subject: Re: RFC: NAPI packet weighting patch
From: Andi Kleen <ak@xxxxxxx>
Date: Wed, 22 Jun 2005 23:10:58 +0200
Cc: ak@xxxxxxx, leonid.grossman@xxxxxxxxxxxx, hadi@xxxxxxxxxx, becker@xxxxxxxxx, rick.jones2@xxxxxx, netdev@xxxxxxxxxxx, davem@xxxxxxxxxx
In-reply-to: <20050622.132241.21929037.davem@davemloft.net>
References: <1119458226.6918.142.camel@localhost.localdomain> <200506221801.j5MI11xS021866@guinness.s2io.com> <20050622180654.GX14251@wotan.suse.de> <20050622.132241.21929037.davem@davemloft.net>
Sender: netdev-bounce@xxxxxxxxxxx
On Wed, Jun 22, 2005 at 01:22:41PM -0700, David S. Miller wrote:
> From: Andi Kleen <ak@xxxxxxx>
> Date: Wed, 22 Jun 2005 20:06:55 +0200
> 
> > However it is tricky because CPUs have only a limited load queue
> > entries and doing too many prefetches will just overflow that.
> 
> Several processors can queue about 8 prefetch requests, and
> these slots are independant of those consumed by a load.

8 entries? That sounds very small. Is that an old Sparc or something? :)

An Opteron has 44 entries, effectively 32 for L2.   Netburst
or POWER4 derived CPUs have more than that.

> Yes, if you queue too many prefetches, the queue overflows.
> 
> I think the optimal scheme would be:
> 
> 1) eth_type_trans() info in RX descriptor
> 2) prefetch(skb->data) done as early as possible in driver
>    RX handling
> 
> Actually, I believe to most optimal scheme is:

Looks reasonable. Not sure about the "most optimal" though, some benchmarking
of different schemes would be probably a good idea.

-Andi

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