On 02/08/2016 11:14 AM, Vladislav Yasevich wrote: > This is an RFC series to extend macvtap with multiple qdisc. Right now > multiqueue macvtap setups suffer from lock contention. Macvtap sets > the queue index and thus gets a default qdisc allocated to it. Since > it later users dev_queue_xmit() call to the macvlan type device (so that > we can packet captures and other filtering on macvtap itself) we end up > with qdisc lock contention since what we have is multiple file descriptors > writing to the same qdisc. > > With this series, the macvtap device now becomes a true multi-queue device > that defaults to 1 queue. Every time the user opens the device (this is > how multiqueue macvtap is used), we update the number of real queues for > the device. When the user writes to the device, we record the queue index > associted with the file descriptor to the skb, and that ends up translating > to the device queue index. This is one transmit only. Receive side > is left alone and will prefer skb hash if available. > > Macvlan through this all is left with lockless transmit path. > > Thanks > -vlad
A question is do we really want a qdisc for macvtap (and other pseudo device)? If yes, the "problem" may not be specific to macvtap. Consider you may get contention after place a qdisc on vlan device. If not, probably a one line patch with IFF_NO_QUEUE is sufficient? Thanks > > Vladislav Yasevich (3): > macvtap: mutiple qdiscs support > macvlan: add queue selection functionality > macvtap: Record the rx queue based on the user tap queue > > drivers/net/macvlan.c | 20 ++++++++++++++++++++ > drivers/net/macvtap.c | 19 +++++++++++++++++++ > 2 files changed, 39 insertions(+) >
