On Tue, 2016-09-13 at 15:59 -0700, Michael Ma wrote: > Hi - > > We currently use mqprio on ifb to work around the qdisc root lock > contention on the receiver side. The problem that we found was that > queue_mapping is already set when redirecting from ingress qdisc to > ifb (based on RX selection, I guess?) so the TX queue selection is not > based on priority. > > Then we implemented a filter which can set skb->queue_mapping to 0 so > that TX queue selection can be done as expected and flows with > different priorities will go through different TX queues. However with > the queue_mapping recomputed, we found the achievable bandwidth with > small packets (512 bytes) dropped significantly if they're targeting > different queues. From perf profile I don't see any bottleneck from > CPU perspective. > > Any thoughts on why modifying queue_mapping will have this kind of > effect? Also is there any better way of achieving receiver side > throttling using HTB while avoiding the qdisc root lock on ifb?
But, how many queues do you have on your NIC, and have you setup ifb to have a same number of queues ? There is no qdisc lock contention anymore AFAIK, since each cpu will use a dedicate IFB queue and tasklet.
