[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1304052880.2954.18.camel@edumazet-laptop>
Date: Fri, 29 Apr 2011 06:54:40 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: John Lumby <johnlumby@...mail.com>
Cc: Francois Romieu <romieu@...zoreil.com>, netdev@...r.kernel.org,
Ben Hutchings <bhutchings@...arflare.com>, nic_swsd@...ltek.com
Subject: Re: r8169 : always copying the rx buffer to new skb
Le jeudi 28 avril 2011 à 21:55 -0400, John Lumby a écrit :
> *
> Conclusions :
> . setting copybreak to 16383 seems to be a valid way of avoiding
> alloc failures when under heavy memory pressure, although the alloc
> failures don't seem to cause much trouble in these runs.
> . But I am surprised to see how well the copybreak=16383 case runs
> with no memory pressure, much better than I saw for the unpatched
> 2.6.39rc2 earlier on, and I need to run some more tests to check
> that. I will also run same tests on the vanilla 2.6.39.
Doing the copy of data and building an exact size skb has benefit of
providing 'right' skb->truesize (might reduce RCVBUF contention and
avoid backlog drops) and already cached data (hot in cpu caches). Next
'copy' is almost free (L1 cache access)
It all depends on workload. If you want to receive a huge number of
small datagrams, [and feed them to several cpus], results might be
completely different.
> . for my next patch submission - what should I base it on?
> Is there a git project which has the "latest" version of r8169.c? I
> think it's not torvalds/linux-2.6.git as fixes to r8169.c in that
> project go only to 2011-03-21. Sorry if this is dumb question.
This one ?
http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists