On Fri, 2016-05-20 at 09:29 +0200, Jesper Dangaard Brouer wrote:
> The hole idea behind allowing bulk qdisc dequeue, was to mitigate this, > by allowing dequeue to do more work, while holding the lock. > > You mention HTB. Notice HTB does not take advantage of bulk dequeue. > Have you tried to enable/allow HTB to bulk dequeue? > Well, __QDISC___STATE_RUNNING means exactly that : one cpu is dequeueing many packets from the qdisc and tx them to the device. It is generic for any kind of qdisc. HTB bulk dequeue would have to call ->dequeue() mutiple times. If you do this while holding qdisc spinlock, you block other cpus from doing concurrent ->enqueue(), adding latencies (always the same trade off...) HTB wont be anytime soon have separate protections for the ->enqueue() and the ->dequeue(). Have you looked at this monster ? I did, many times... Note that I am working on a patch to transform __QDISC___STATE_RUNNING to a seqcount do that we can grab stats without holding the qdisc lock.
