Kevin Darbyshire-Bryant <[email protected]> writes: >> On 25 Apr 2018, at 21:45, Toke Høiland-Jørgensen <[email protected]> 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 [email protected] https://lists.bufferbloat.net/listinfo/cake
