From: Eric Dumazet <firstname.lastname@example.org> To: Rick Jones <email@example.com> Cc: David Miller <firstname.lastname@example.org>, netdev <email@example.com>, Yuchung Cheng <firstname.lastname@example.org>, Neal Cardwell <email@example.com>, Michael Kerrisk <firstname.lastname@example.org> Subject: Re: [PATCH v3 net-next 2/2] tcp: TCP_NOTSENT_LOWAT socket option Date: Tue, 23 Jul 2013 08:44:04 -0700 [thread overview] Message-ID: <1374594244.3449.13.camel@edumazet-glaptop> (raw) In-Reply-To: <51EEA089.email@example.com> 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. > > Anyway, on a more "how to use netperf" theme, while the final confidence > interval width wasn't reported, given the combination of -l 20, -i 10,3 > and perf stat reporting an elapsed time of 200 seconds, we can conclude > that the test went the full 10 iterations and so probably didn't > actually hit the desired confidence interval of 5% wide at 99% probability. > > 17321.16 Mbit/s is ~132150 16 KB sends per second. There were roughly > 13,379 context switches per second, so not quite 10 sends per context > switch (~161831 bytes , that then is something like 161831 KB per > context switch. Does that then imply you could have achieved nearly the > same performance with test-specific -s 160K -S 160K -m 16K ? (perhaps a > bit more than that socket buffer size for contingencies and or what was > "stored"/sent in the pipe?) Or, given that the SO_SNDBUF grew to > 1593240 bytes, was there really a need for ~ 1593240 - 131072 or > ~1462168 sent bytes in flight most of the time? > Heh, you are trying the old crap again ;) Why should we care of setting buffer sizes at all, when we have autotuning ;) 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. 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.
next prev parent reply other threads:[~2013-07-23 15:44 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 [this message] 2013-07-23 16:20 ` Rick Jones 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=1374594244.3449.13.camel@edumazet-glaptop \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v3 net-next 2/2] tcp: TCP_NOTSENT_LOWAT socket option' \ /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
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).