[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: <>
References: <1119458226.6918.142.camel@localhost.localdomain> <> <> <>
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.


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