Re: [Bloat] sweeping up the bloat

[Eric Dumazet <eric.dumazet@gmail.com>]

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.

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

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

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


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