Re: [RFC PATCH net-next] qfq: handle the case that front slot is empty

[Eric Dumazet <eric.dumazet@gmail.com>]

On Fri, 2012-10-26 at 09:51 +0200, Paolo Valente wrote:

> I think I will ask for your help soon, thanks.
> 
> The cause of the failure is TCP segment offloading, which lets qfq
> receive packets with a much larger size than the MTU of the device.
> In this respect, under qfq the default max packet size lmax for each
> class (2KB) is only slightly higher than the MTU. Violating the lmax
> constraint causes the corruption of the data structure that implements
> the bucket lists of the groups. In fact, the failure that you found is
> only one of the consequences of this corruption. I am sorry I did not
> discover it before, but, foolishly, I have run only UDP tests.
> 
> I am thinking about the best ways for addressing this issue.
> 
> BTW, I think that the behavior of all the other schedulers should be
> checked as well. For example, with segment offloading, drr must
> increment the deficit of a class for at most (64K/quantum) times,
> i.e., rounds, before it can serve the next packet of the class. The
> number of instructions per packet dequeue becomes therefore
> (64K/quantum) times higher than without segment offloading.
> 

OK, good to know you found the problem.

Normally, TSO is supported by other qdisc, maybe not optimally but
supported.

For example, one known problem with TSO is that skb->len is a
underestimation of real number of bytes sent on wire

If MSS is a bit small, TBF/HTB/CBQ can really overdrive links.

We probably should have a more precise estimation.