On Thu, 26 Apr 2018, Sebastian Moeller wrote:
On Apr 26, 2018, at 09:26, Jonathan Morton <[email protected]> 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
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
