On Thu, Sep 19, 2019 at 7:01 AM Or Gerlitz <gerlitz...@gmail.com> wrote: > > On Thu, Sep 19, 2019 at 4:46 PM Eric Dumazet <eric.duma...@gmail.com> wrote: > > On 9/19/19 5:17 AM, Or Gerlitz wrote: > > > On Wed, Sep 11, 2019 at 12:54 AM Eric Dumazet <eduma...@google.com> wrote: > > >> When tcp sends a TSO packet, adding a PSH flag on it > > >> reduces the sojourn time of GRO packet in GRO receivers. > > >> > > >> This is particularly the case under pressure, since RX queues > > >> receive packets for many concurrent flows. > > >> > > >> A sender can give a hint to GRO engines when it is > > >> appropriate to flush a super-packet, especially when pacing > > > > Is this correct that we add here the push flag for the tcp header template > > > from which all the tcp headers for SW GSO packets will be generated? > > > Wouldn't that cause a too early flush on GRO engines at the receiver side? > > > If a TSO engine is buggy enough to add the PSH on all the segments, it needs > > to be fixed urgently :) > > yeah, but I guess you were not able to test this over all the TSO HWs > out there.. > so I guess if someone complains we will have to add a quirk to disable > that, lets see..
The only known pain point for TSO is the ECN part (probably was missed by first Microsoft specs) This is why we have NETIF_F_TSO_ECN
