Netdev List
 help / color / mirror / Atom feed
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




  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