[Cake] CAKE upstreaming - testers wanted, ACK filtering rescuers needed
David Lang
david at lang.hm
Thu Apr 26 20:17:08 EDT 2018
On Thu, 26 Apr 2018, Sebastian Moeller wrote:
>> On Apr 26, 2018, at 09:26, Jonathan Morton <chromatix99 at gmail.com> wrote:
>>
>>> 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 have it exactly right. For some reason, Eric is failing to consider the general case of flow-isolating queues at low link rates, and only considering high-rate FIFOs.
>>
>> More to the point, at 64Kbps a maximal GSO packet can take 8 seconds to clear, while an MTU packet takes less than a quarter second!
>
> I venture a guess that it is not so much the concept but rather the
> terminology that irritates Eric? If at all Superpackets lighten the kernel's
> load and will in all likelihood make in-kernel processing faster which if at
> all decreases latency. The effect on flow fairness that we are concerned about
> might simply not register under "latency" for the kernel developers; I am sure
> they see the issue and this is really about which words to use to describe
> this... Also I point at the fact that Eric did not object to the feature per
> se, but rather the unconditionality and the rationale.
Keep in mind that he was also griping about the focus on <100M bandwidth limits
and talking about >10G links. At those speeds, the large GSO packet is not a
significant factor.
David Lang
More information about the Cake
mailing list