[Bloat] sweeping up the bloat

[Dave Taht]

On Tue, Jun 16, 2015 at 11:32 AM, Eric Dumazet <eric.dumazet at gmail.com> wrote:
> On Tue, 2015-06-16 at 10:53 -0700, Dave Taht wrote:
>
>> But guidelines on how to configure it in applications are missing.
>
> Well, you know the optimal rate -> set it. It is that simple.
>
> If not, leave this to TCP stack.
>
>>  As
>> are when where and how to implement it in DCs, handheld clients,
>> internal servers and hosts, home routers, slow networks, VMs, and bare
>> metal servers.
>>
>> Quic does pacing, so far as I know, entirely in userspace, or does it
>> rely on sch_fq to do so? Should a VOIP app or server like freeswitch
>> use it?
>
> A Quic server handles thousands (millions ?) of flows. Having one kernel
> socket per flow would be way too expensive.
>
> (And BTW, rx path in UDP is not optimized for 4-tuple hashing).
>
> There are 2 hash tables, one lookup on destination_IP:destination_port,
> and one on *:destination_port.
>
> For Quic server, all sockets would share same keys.

thank you. I am watching the progress on the github libs for quic with
great anticipation.

>>
>> I see in the kernel support for sk_pacing_rate, and max_pacing_rate
>> and it is unclear how/when those options can be of aid and set.
>
> Really ?
>
> You haven't try hard, and this is quite upsetting given your concerns.

Consider the last few weeks as "trying harder".

While I have great enthusiasm for all the improvements in e2e stuff,
my time for any of it shrank considerably while keeping a roof over my
head with largely irrellevant work, teasing the long tail of folk that
still believed in reno, bringing up new devices that were 2.6 based
(sigh), and stabilizing openwrt stuff for a new re-deployment on 3.18,
that had significant breakages in babel (1.6.1 is due tonight),
dnsmasq (2.73 just released) and ongoing issues in hnetd, and dhcp-pd.

toke's testbed remains at 3.14. My principal server is still 3.9.

In recent months I have established 3.19 servers all over the world to
test with, but have not got around to doing anything truly coherent
with them. Next step was to add them to the flent pool. been
distracted by "cake".

but my ongoing, massive, step, has been to try to assemble sufficient
solutions and resources to tackle make-wifi-fast at all layers 0-10,
which has eaten most of my "spare" time for many, many months now.

Jim is focused on other things, and I long ago hit "overwhelm" with
the resources I had.

Only now, am I trying to catch up on all the good stuff that has
happened e2e since I last could pay any attention, and it seemed like
a better idea to instead be trying to find people willing to step up
on all other fronts in the bufferbloat battle.

I gotta admit, bufferbloat.net was a lot more fun 4+ years ago. I
stopped scaling shortly before we finalized cerowrt.

I am all in favor of a top down level perspective from you and all
others of this effort as to what we (And I) should be prioritizing in
the future. Closing up shop entirely is also an option.

For fun, these days, I hack on FPGAs.

> http://www.spinics.net/lists/netdev/msg251368.html

Although *I* read all your commits every month (which used to be
daily), I only grepped the kernel for "pacing" just now. There is for
example, nothing on it in Documentation/networking . There are no
patches in open source code enabling it that I can find, actually
using SO_MAX_PACING_RATE. It IS in my glibc headers, but
TCP_NOTSENT_LOWAT is not, which is sort of what sparked this thread -
what good had happened since I last paid attention, and how far had it
spread?

So I think a little more outreach and example patches for various
common applications is needed. From everybody.

> u32 val = 1000000;
> setsockopt(sockfd, SOL_SOCKET, SO_MAX_PACING_RATE, &val, sizeof(val));

Thx. flent and/or netperf could use a fixed rate sender test exercising this.

> Can it be simpler than that ? (In C I mean...)

Heh. Nope.

>
>
>



-- 
Dave Täht
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast