> 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

Reply via email to