(Sorry for missing this email, it is lost in other discussions.) On Wed, Jul 11, 2018 at 8:25 AM Michel Machado <mic...@digirati.com.br> wrote: > > On 07/10/2018 10:57 PM, Cong Wang wrote: > > The dev->tx_queue_len is fundamentally non-sense since now > > almost every real NIC is multi-queue and qdisc has a completely > > different sch->limit. This is why I suggested you to simply > > avoid it in your code. > > Would you be okay with a constant there? If so, we could just put 64 > there. The optimal number is hardware dependent, but we don't know how > to calculate it.
Yes, sure, fq_codel uses 10240 already. :) > > > There is no standard way to use dev->tx_queue_len in kernel, > > so I can't claim your use is correct or not, but it still looks odd, > > other qdisc seems just uses as a default, rather than picking > > the smaller or bigger value as a cap. > > The reason for the `max(qdisc_dev(sch)->tx_queue_len, min_limit)` is > to make sure that sch->limit is at least 1. We couldn't come up with a > meaningful behavior for sch->limit being zero, so we defined the basis > case of skbprio_enqueue() as sch->limit one. If there's a guarantee that > qdisc_dev(sch)->tx_queue_len is always greater than zero, we don't need > the max(). I think tx_queue_len could be 0. But again, why do you need to care about tx_queue_len being 0 or not here? sch->limit could be 0 too, it means this qdisc should not queue any packets. Thanks
