Re: [RFC PATCH net-next 0/3] Extend macvtap with multiple qdiscs

[Jason Wang <jasowang@redhat.com>]

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(+)
>