Thread (40 messages) 40 messages, 5 authors, 2010-09-03

Re: [RFC] gro: Is it ok to share a single napi from several devs ?

From: Jarek Poplawski <hidden>
Date: 2010-08-30 18:38:25

On Mon, Aug 30, 2010 at 09:50:12AM -0700, David Miller wrote:
From: Stephen Hemminger <redacted>
Date: Mon, 30 Aug 2010 08:57:21 -0700
quoted
On Mon, 30 Aug 2010 06:42:31 +0000
Jarek Poplawski [off-list ref] wrote:
quoted
On 2010-08-29 20:39, Eric Dumazet wrote:
quoted
Le dimanche 29 aoĂťt 2010 Ă  10:06 -0700, David Miller a ĂŠcrit :
quoted
From: Jarek Poplawski <redacted>
Date: Sun, 29 Aug 2010 11:59:51 +0200
quoted
Actually, when GRO compares napi->dev to skb->dev?
Hmmm, I thought the code made a skb->dev comparison with the
existing SKBs in the list when checking for same-flow matches.

It doesn't, probably based upon the assumption that a NAPI
instance maps to a unique device, the very topic we're
discussing right now :-/
It does the check, Stephen added it in the commit I mentioned to start
this thread.

With net-next-2.6 this now reads :
Since Stephen didn't seem to miss this too much it seems quite obvious
to me this check should be removed.
No. I just don't use that system much, breaking code for
sake of one comparison is ridiculous.
It's not working to begin with.
IMHO it should work yet. On the other hand, after removing this test
GRO should still work OK for these NICs in most cases, so it should be
treated as an optimization only. And it seems very unusual to keep such
optimizations at this level for such rare cases.
I agree with Jarek that the check should be removed.  And GRO is one
of those places that, precisely, even one memory reference removal
can improve performance dramatically.
Hmm... I proposed removal when Stephen didn't defend it. Since he
seems to change his line, I'd prefer to be convinced I'm wrong,
preferably with some use/test case; most preferably from some
desperated user...
Herbert spent a lot of time doing micro-optimizations to make GRO
better and better, and the smallest things can turn out to make a huge
difference there.
Anyway, after the last Eric's optimization, it's almost invisible...

Jarek P.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help