From: Rick Jones <rick.jones2@hp.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Miller <davem@davemloft.net>,
netdev <netdev@vger.kernel.org>,
Yuchung Cheng <ycheng@google.com>,
Neal Cardwell <ncardwell@google.com>,
Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Re: [PATCH v3 net-next 2/2] tcp: TCP_NOTSENT_LOWAT socket option
Date: Tue, 23 Jul 2013 09:20:36 -0700 [thread overview]
Message-ID: <51EEAD54.2040603@hp.com> (raw)
In-Reply-To: <1374594244.3449.13.camel@edumazet-glaptop>
On 07/23/2013 08:44 AM, Eric Dumazet wrote:
> On Tue, 2013-07-23 at 08:26 -0700, Rick Jones wrote:
>
>> I see that now the service demand increase is more like 8%, though there
>> is no longer a throughput increase. Whether an 8% increase is not a bad
>> effect on the CPU usage of a single flow is probably in the eye of the
>> beholder.
>
> Again, it seems you didn't understand the goal of this patch.
>
> It's not trying to get lower cpu usage, but lower memory usage, _and_
> proper logical splitting of the write queue.
Right - I am questioning whether it is worth the CPU increase.
> Heh, you are trying the old crap again ;)
Yes - why do you seem to be resisting?-)
> Why should we care of setting buffer sizes at all, when we have
> autotuning ;)
Because it keeps growing the buffer too large?-)
> RTT can vary from 50us to 200ms, rate can vary dynamically as well, some
> AQM can trigger with whatever policy, you can have sudden reorders
> because some router chose to apply per packet load balancing :
>
> - You do not want to hard code buffer sizes, but instead let TCP stack
> tune it properly.
I agree that is far nicer if it can be counted upon to work well.
> Sure, I can probably can find out what are the optimal settings for a
> given workload and given network to get minimal cpu usage.
>
> But the point is having the stack finds this automatically.
>
> Further tweaks can be done to avoid a context switch per TSO packet for
> example. If we allow 10 notsent packets, we can probably wait to have 5
> packets before doing a wakeup.
Isn't this change really just trying to paper-over the autotuning's
over-growing of the socket buffers? Or are you considering it an
extension of the auto-tuning heuristics?
If your 20Gbit test setup needed only 256KB socket buffers (figure
pulled form the ether) to get to 17 Gbit/s, isn't the autotuning's
growing them to several MB a bug in the autotuning?
rick
next prev parent reply other threads:[~2013-07-23 16:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-23 3:27 [PATCH v3 net-next 2/2] tcp: TCP_NOTSENT_LOWAT socket option Eric Dumazet
2013-07-23 3:52 ` Hannes Frederic Sowa
2013-07-23 15:26 ` Rick Jones
2013-07-23 15:44 ` Eric Dumazet
2013-07-23 16:20 ` Rick Jones [this message]
2013-07-23 16:48 ` Eric Dumazet
2013-07-23 17:18 ` Eric Dumazet
2013-07-23 18:24 ` Yuchung Cheng
2013-07-25 0:55 ` David Miller
2013-07-23 19:19 Neal Cardwell
2013-07-23 19:28 Neal Cardwell
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=51EEAD54.2040603@hp.com \
--to=rick.jones2@hp.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=mtk.manpages@gmail.com \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=ycheng@google.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;
as well as URLs for NNTP newsgroup(s).