On Thu, 26 Apr 2018, Sebastian Moeller wrote: >> On Apr 26, 2018, at 09:26, Jonathan Morton 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