[Codel] The next slice of cake

[Jonathan Morton]

>>> On 22 Mar, 2015, at 11:39, Sebastian Moeller <moeller0 at gmx.de> wrote:
>>> 
>>> I could be out to lunch here, as usual,;but I argue the byte limit should include the kernel overhead (could this be based on skb->truesize) as this is what counts against real memory. My assumption here is that in normal operation we rarely/never get queues to fill up to the limit anyways
>> 
>> Such an argument could certainly be made.  Does skb->truesize include the skb header, as well as the buffer space allocated?
> 
> 	According to http://vger.kernel.org/~davem/skb_sk.html (“We keep track of how many bytes of system memory are consumed by a packet in 'skb->truesize'. This is the total of how large a data buffer we allocated for the packet, plus the size of 'struct sk_buff' itself.") it looks like this should be the right number, but I am not well versed in reading kernel code, so there might be some caveats I am not aware of.

The statement in that commentary seems to be authoritative enough to rely on.

>>> (as tho would turn the queue into tail-drop effectively)
>> 
>> But fq_codel (and cake) are a little cleverer than that, even when they hit the hard limit.  They still drop from the head, and they shoot the longest flow-queue first.
> 
> 	Excellent, learned something new today; in fq_codel does this come from the per-codel instance 1000 packet limit or from the default fq_codel 102400? packet limit (just in case someone knows off hand, I can try to understand the kernel code myself, given enough time ;) )?

Off the top of my head, most likely both.  (If a per-queue limit is hit, then by definition that’s the longest queue.)

I should probably re-read the code to be certain of that, though.  I’m currently eyeball-deep in running software updates on half a dozen very obsolete machines, and cracking the cases on half a dozen routers to see what hardware they’ve got inside.  So far I think *one* of them has actually matched what the OpenWRT database lists, and even then there’s an obvious error.

 - Jonathan Morton