> On Apr 25, 2018, at 18:52, Jonathan Morton <[email protected]> wrote:
>
>> We can see here the high cost of forcing software GSO :/
>>
>> Really, this should be done only :
>> 1) If requested by the admin ( tc .... gso ....)
>>
>> 2) If packet size is above a threshold.
>> The threshold could be set by the admin, and/or based on a fraction of the
>> bandwidth parameter.
>>
>> I totally understand why you prefer to segment yourself for < 100 Mbit links.
>>
>> But this makes no sense on 10Gbit+
>
> It is absolutely necessary, so far as I can see, to segment GSO superpackets
> when overhead compensation is selected - as it very often should be, even on
> pure Ethernet links. Without that, the calculation of link occupancy time
> will be wrong. (The actual transmission time of an Ethernet frame is rather
> more than just 14 bytes longer than the underlying IP packet.)
To elaborate a bit: For most link technologies the number of
on-the-wire segments (and the total IP size of the superpacket) would go a long
way, but for ATM with its mandatory per packet padding (to fill an integer
number of ATM cells) one really needs to know the precise packet size.
>
> Another reason to apply GSO segmentation is to achieve maximal smoothness of
> flow isolation. This should still be achievable within some tolerance at
> high link rates, but calculating this tolerance is complicated by the
> triple-isolate algorithm.
>
> If there's a way to obtain the individual packet sizes without incurring the
> full segmentation overhead, it may be worth considering (at high link rates
> only). I would want to leave it on by default, because some of Cake's
> demonstrably superior latency performance depends on seeing the real packets,
> not the aggregates, and the overhead only becomes significant above 100Mbps
> on weak MIPS CPUs and 1Gbps on vaguely modern x86 stuff.
>
> - Jonathan Morton
>
> _______________________________________________
> Cake mailing list
> [email protected]
> https://lists.bufferbloat.net/listinfo/cake
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake