From: John Lumby <johnlumby@hotmail.com>
To: Francois Romieu <romieu@fr.zoreil.com>
Cc: 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: Thu, 28 Apr 2011 21:55:38 -0400 [thread overview]
Message-ID: <4DBA1A9A.3000703@hotmail.com> (raw)
In-Reply-To: <20110427203544.GB19708@electric-eye.fr.zoreil.com>
On 04/27/11 16:35, Francois Romieu wrote:
>
> The patch mixes different changes. Please avoid it.
Sorry about that, I'll rewrite with only the changes absolutely needed
for avoiding memcpy (and maybe the setting of num_rx_bufs ring param?)
> Your MUA damaged the patch. Documentation/SubmittingPatches
> could help if you have not read it yet.
I see some truncation happened, will fix that in next submission
> The patch makes some gratuitous changes which needlessly
> increase the differences (dirty_xy rename for instance).
will revert those
> A set_ringparam() method which does nothing until open()
> is used does not exactly ring like "least surprize behavior"
> to me.
Please see questions below
> The behavior under memory pressure is still unknown.
I have run some initial tests with memory pressure - the pressure
provided by running n concurrent memory hogs, each of which loops
endlessly on allocating 1024 blocks of 1MB bytes each, writing
something into all bytes in each block, then freeing each block,
then repeating. result:
*
copybreak numhogs workload throughput swapping alloc
failures? dropped packets
Mb/sec or other NIC err reports?
16383 0 1043 none
no no
64 0 1086 |
no no
16383 1 935 moderate
no no
64 1 902 |
no no
16383 2 854 heavy
no no
64 2 851 | yes,
many no
16383 3 817 very heavy
no no
64 3 did not attempt |
*
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.
> I am mildly convinced by the implementation.
>
Thanks for all comments.
I do have a couple more questions:
. 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.
. regarding setting the ring param - I understand your comment
but is it safe to close and open the NIC when called by ethtool
ioctl? Would some locking be needed?
. and again on the ring params - what is the minimum and
maximum valid value for num rx bufs and separately for num tx bufs
that the r8169 supports?
Cheers, John Lumby
next prev parent reply other threads:[~2011-04-29 1:55 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 [this message]
2011-04-29 4:54 ` Eric Dumazet
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=4DBA1A9A.3000703@hotmail.com \
--to=johnlumby@hotmail.com \
--cc=bhutchings@solarflare.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.