Re: [Cake] CAKE upstreaming - testers wanted, ACK filtering rescuers needed

[David Lang <david@lang.hm>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1880 bytes --]

On Thu, 26 Apr 2018, Sebastian Moeller wrote:

>> On Apr 26, 2018, at 09:26, Jonathan Morton <chromatix99@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