[Cake] CAKE upstreaming - testers wanted, ACK filtering rescuers needed
Jonas Mårtensson
martensson.jonas at gmail.com
Thu Apr 26 04:43:53 EDT 2018
"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 at toke.dk>
wrote:
> Kevin Darbyshire-Bryant <kevin at darbyshire-bryant.me.uk> writes:
>
> >> On 25 Apr 2018, at 21:45, Toke Høiland-Jørgensen <toke at 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20180426/622df212/attachment-0001.html>
More information about the Cake
mailing list