>>> On 22 Mar, 2015, at 11:39, Sebastian Moeller <[email protected]> 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 _______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
