"I *think* that what Eric means is that the GSO logic should automatically
size the GSO superpackets so the latency cost is negligible for the actual
link rate."

Something like this?

https://lwn.net/Articles/564979/

https://lwn.net/Articles/564978/

/Jonas

On Thu, Apr 26, 2018 at 9:34 AM, Toke Høiland-Jørgensen <toke@toke.dk>
wrote:

> Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> writes:
>
> >> On 25 Apr 2018, at 21:45, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> >>
> >> For those who have not been following the discussion on the upstreaming
> >> patches, here's an update:
> >>
> >> <snip>
> >>
> >> So please do test the current git version (cobalt branch, still). I'm
> >> planning to resubmit on Friday.
> >
> > The two routers running that latest code survived the night which is a
> > good sign.
>
> Awesome!
>
> > I’ve sort of half been following the ‘discussion’, as ever the
> > reaction from the kernel people makes it a place I never wish to
> > look/contribute, ….. this from Eric has me disturbed "If you keep
> > saying this old urban legend, I will NACK your patch.I am tired of
> > people pretending GSO/TSO are bad for latencies.”
>
> Heh, yeah, the tone on kernel lists can be a bit... abrasive... just
> smile and wave and ignore the vitriol is my approach. But I can totally
> understand why some people don't want to put up with it... :)
>
> > Genuine question:  I have a superpacket circa 64K, this is a lump of
> > data in a tcp flow.  I have another small VOIP packet, it’s latency
> > sensitive.  If I split the super packet into individual 1.5K packets
> > as they would be on the wire, I can insert my VOIP packet at suitable
> > place in time such that jitter targets are not exceeded.  If I don’t
> > split the super packet, surely I have to wait till the end of the
> > superpacket’s queue (for want of a better word) and possibly exceed my
> > latency target.  That looks to me like ‘GSO/TSO’ is potentially bad
> > for interflow latencies.  What don’t I understand here?
>
> You are right in principle, of course. I *think* that what Eric means is
> that the GSO logic should automatically size the GSO superpackets so the
> latency cost is negligible for the actual link rate. I was actually
> thinking I would do some measurements at some point to test this at
> various rates; since we have a nice piece of code that can adaptively
> split GSO packets that should be pretty straight-forward :)
>
> -Toke
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>