Re: Modification to skb->queue_mapping affecting performance

2016-09-23 Thread Michael Ma
2016-09-16 15:00 GMT-07:00 Michael Ma : > 2016-09-16 12:53 GMT-07:00 Eric Dumazet : >> On Fri, 2016-09-16 at 10:57 -0700, Michael Ma wrote: >> >>> This is actually the problem - if flows from different RX queues are >>> switched to the same RX queue in IFB, they'll use different processor >>> conte

Re: Modification to skb->queue_mapping affecting performance

2016-09-16 Thread Michael Ma
2016-09-16 12:53 GMT-07:00 Eric Dumazet : > On Fri, 2016-09-16 at 10:57 -0700, Michael Ma wrote: > >> This is actually the problem - if flows from different RX queues are >> switched to the same RX queue in IFB, they'll use different processor >> context with the same tasklet, and the processor con

Re: Modification to skb->queue_mapping affecting performance

2016-09-16 Thread Eric Dumazet
On Fri, 2016-09-16 at 10:57 -0700, Michael Ma wrote: > This is actually the problem - if flows from different RX queues are > switched to the same RX queue in IFB, they'll use different processor > context with the same tasklet, and the processor context of different > tasklets might be the same.

Re: Modification to skb->queue_mapping affecting performance

2016-09-16 Thread Michael Ma
2016-09-15 17:51 GMT-07:00 Michael Ma : > 2016-09-14 10:46 GMT-07:00 Michael Ma : >> 2016-09-13 22:22 GMT-07:00 Eric Dumazet : >>> On Tue, 2016-09-13 at 22:13 -0700, Michael Ma wrote: >>> I don't intend to install multiple qdisc - the only reason that I'm doing this now is to leverage MQ

Re: Modification to skb->queue_mapping affecting performance

2016-09-15 Thread Michael Ma
2016-09-14 10:46 GMT-07:00 Michael Ma : > 2016-09-13 22:22 GMT-07:00 Eric Dumazet : >> On Tue, 2016-09-13 at 22:13 -0700, Michael Ma wrote: >> >>> I don't intend to install multiple qdisc - the only reason that I'm >>> doing this now is to leverage MQ to workaround the lock contention, >>> and base

Re: Modification to skb->queue_mapping affecting performance

2016-09-14 Thread Michael Ma
2016-09-13 22:22 GMT-07:00 Eric Dumazet : > On Tue, 2016-09-13 at 22:13 -0700, Michael Ma wrote: > >> I don't intend to install multiple qdisc - the only reason that I'm >> doing this now is to leverage MQ to workaround the lock contention, >> and based on the profile this all worked. However to si

Re: Modification to skb->queue_mapping affecting performance

2016-09-13 Thread Eric Dumazet
On Tue, 2016-09-13 at 22:13 -0700, Michael Ma wrote: > I don't intend to install multiple qdisc - the only reason that I'm > doing this now is to leverage MQ to workaround the lock contention, > and based on the profile this all worked. However to simplify the way > to setup HTB I wanted to use TX

Re: Modification to skb->queue_mapping affecting performance

2016-09-13 Thread Michael Ma
2016-09-13 22:13 GMT-07:00 Michael Ma : > 2016-09-13 18:18 GMT-07:00 Eric Dumazet : >> On Tue, 2016-09-13 at 17:23 -0700, Michael Ma wrote: >> >>> If I understand correctly this is still to associate a qdisc with each >>> ifb TXQ. How should I do this if I want to use HTB? I guess I'll need >>> to

Re: Modification to skb->queue_mapping affecting performance

2016-09-13 Thread Michael Ma
2016-09-13 18:18 GMT-07:00 Eric Dumazet : > On Tue, 2016-09-13 at 17:23 -0700, Michael Ma wrote: > >> If I understand correctly this is still to associate a qdisc with each >> ifb TXQ. How should I do this if I want to use HTB? I guess I'll need >> to divide the bandwidth of each class in HTB by th

Re: Modification to skb->queue_mapping affecting performance

2016-09-13 Thread Eric Dumazet
On Tue, 2016-09-13 at 17:23 -0700, Michael Ma wrote: > If I understand correctly this is still to associate a qdisc with each > ifb TXQ. How should I do this if I want to use HTB? I guess I'll need > to divide the bandwidth of each class in HTB by the number of TX > queues for each individual HTB

Re: Modification to skb->queue_mapping affecting performance

2016-09-13 Thread Michael Ma
2016-09-13 17:09 GMT-07:00 Eric Dumazet : > On Tue, 2016-09-13 at 16:30 -0700, Michael Ma wrote: > >> The RX queue number I found from "ls /sys/class/net/eth0/queues" is >> 64. (is this the correct way of identifying the queue number on NIC?) >> I setup ifb with 24 queues which is equal to the TX q

Re: Modification to skb->queue_mapping affecting performance

2016-09-13 Thread Eric Dumazet
On Tue, 2016-09-13 at 16:30 -0700, Michael Ma wrote: > The RX queue number I found from "ls /sys/class/net/eth0/queues" is > 64. (is this the correct way of identifying the queue number on NIC?) > I setup ifb with 24 queues which is equal to the TX queue number of > eth0 and also the number of CPU

Re: Modification to skb->queue_mapping affecting performance

2016-09-13 Thread Eric Dumazet
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

Modification to skb->queue_mapping affecting performance

2016-09-13 Thread Michael Ma
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.