archive mirror
 help / color / mirror / Atom feed
From: Rick Jones <>
To: Eric Dumazet <>
Cc: David Miller <>,
	netdev <>,
	Yuchung Cheng <>,
	Neal Cardwell <>,
	Michael Kerrisk <>
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: <> (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?


  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 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v3 net-next 2/2] tcp: TCP_NOTSENT_LOWAT socket option' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).