On Tue, 2018-02-20 at 10:32 +0100, Oleksandr Natalenko wrote: > Hi. > > 19.02.2018 20:56, Eric Dumazet wrote: > > Switching TCP to GSO mode, relying on core networking layers > > to perform eventual adaptation for dumb devices was overdue. > > > > 1) Most TCP developments are done with TSO in mind. > > 2) Less high-resolution timers needs to be armed for TCP-pacing > > 3) GSO can benefit of xmit_more hint > > 4) Receiver GRO is more effective (as if TSO was used for real on > > sender) > > -> less ACK packets and overhead. > > 5) Write queues have less overhead (one skb holds about 64KB of > > payload) > > 6) SACK coalescing just works. (no payload in skb->head) > > 7) rtx rb-tree contains less packets, SACK is cheaper. > > 8) Removal of legacy code. Less maintenance hassles. > > > > Note that I have left the sendpage/zerocopy paths, but they probably > > can > > benefit from the same strategy. > > > > Thanks to Oleksandr Natalenko for reporting a performance issue for > > BBR/fq_codel, > > which was the main reason I worked on this patch series. > > Thanks for dealing with this that fast. > > Does this mean that the option to optimise internal TCP pacing is still > an open question?
It is not an optimization that is needed, but taking into account that highres timers can have latencies of ~2 usec or more. When sending 64KB TSO packets, having extra 2 usec after every ~54 usec (at 10Gbit) has no big impact, since TCP computes a slightly inflated pacing rate anyway. But when sending one MSS/packet every usec, this definitely can demonstrate a big slowdown. But the anser is yes, I will take a look at this timer drift.
