Re: [Bloat] benefits of ack filtering

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

On Thu, 2017-11-30 at 14:04 +0100, Mikael Abrahamsson wrote:
> On Thu, 30 Nov 2017, Eric Dumazet wrote:
> 
> > I agree that TCP itself should generate ACK smarter, on receivers
> > that 
> > are lacking GRO. (TCP sends at most one ACK per GRO packets, that
> > is why 
> > we did not feel an urgent need for better ACK generation)
> 
> Could you elaborate a bit more on the practical implications of the
> above 
> text? What is the typical GRO size used when doing gigabit ethernet 
> transmissions?

Assuming NAPI handler receives a big packet train in one go [1], GRO
packets can be full size (45 MSS -> 65160 bytes of payload assuming
1448 bytes per frame)

[1] GRO engine has an opt-in high res timer helping to extend NAPI poll
if desired. https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-n
ext.git/commit/?id=3b47d30396bae4f0bd1ff0dbcd7c4f5077e7df4e


> 
> So if we're receiving 70kPPS of 1500 byte packets containing 1460
> MSS 
> sized packet (~100 megabyte/s), what would a typical ACK rate be in
> that 
> case?

1) Assuming receiver handles GRO.
2) Assuming few PSH flag set on incoming frames.
3) A default GRO engine on a 10Gbit NIC would probably not aggregate
packets, since 14 usec delay between each packet is too big to let NAPI
handler catch more than 1 packet per NIC RX interrupt.

But setting /sys/class/net/ethX/gro_flush_timeout to 14000 would allow
to build full size GRO packets (45 MSS)

-> TCP receiver would then send 1555 ACK per second instead of 70,000

> 
> In response to some other postings here, my question regarding "is
> 35kPPS 
> really needed" my proposal is not "let's send 50 PPS of ACKs". My
> proposal 
> is if we can't come up with a smarter algorithm than something from
> the 
> 90ties that says "let's send one ACK per 2*MSS" when we today have 
> magnitudes higher rates of forwarding. Also, on for instance DOCSIS 
> networks then you're going to get several ACKs back-to-back anyway 
> (because if they're not pruned by the DOCSIS network, they're anyway
> sent 
> in "bursts" within a single DOCSIS transmit opportunity), so
> imagining 
> that 35kPPS gives you higher resolution than 1kPPS of ACKs is just
> an 
> illusion.
> 
> So if GRO results in (I'm just speculating here) "we're only sending
> one 
> ACK per X kilobytes received if the packets arrived in the same 
> millisecond" and X is in the 16-64 kilobyte range, then that's fine
> by me.
> 
> Any network worth anything should be able to smooth out "bursts" of
> 16-64 
> kilobytes at line rate anyway, in case of egress and the line rate
> there 
> is lower than the sending end is transmitting packets at.
>