From: Eric Dumazet <eric.dumazet@gmail.com>
To: John Lumby <johnlumby@hotmail.com>
Cc: Francois Romieu <romieu@fr.zoreil.com>,
netdev@vger.kernel.org, Ben Hutchings <bhutchings@solarflare.com>,
nic_swsd@realtek.com
Subject: Re: r8169 : always copying the rx buffer to new skb
Date: Fri, 29 Apr 2011 06:54:40 +0200 [thread overview]
Message-ID: <1304052880.2954.18.camel@edumazet-laptop> (raw)
In-Reply-To: <4DBA1A9A.3000703@hotmail.com>
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
next prev parent reply other threads:[~2011-04-29 4:54 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-18 17:08 r8169 : always copying the rx buffer to new skb John Lumby
2011-04-18 17:27 ` Ben Hutchings
2011-04-18 21:26 ` John Lumby
2011-04-20 19:13 ` Francois Romieu
2011-04-21 3:41 ` John Lumby
2011-04-21 3:52 ` John Lumby
2011-04-27 2:18 ` John Lumby
2011-04-27 3:57 ` Eric Dumazet
2011-04-27 20:35 ` Francois Romieu
2011-04-29 1:55 ` John Lumby
2011-04-29 4:54 ` Eric Dumazet [this message]
2011-05-02 19:04 ` Chris Friesen
2011-05-03 11:59 ` hayeswang
2011-04-18 18:21 ` Francois Romieu
-- strict thread matches above, loose matches on Subject: below --
2011-06-27 22:54 John Lumby
2011-06-28 7:55 ` Francois Romieu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1304052880.2954.18.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=bhutchings@solarflare.com \
--cc=johnlumby@hotmail.com \
--cc=netdev@vger.kernel.org \
--cc=nic_swsd@realtek.com \
--cc=romieu@fr.zoreil.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox