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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <56CBC60A.1000404@redhat.com>
Date:	Tue, 23 Feb 2016 10:38:02 +0800
From:	Jason Wang <jasowang@...hat.com>
To:	Vladislav Yasevich <vyasevich@...il.com>, netdev@...r.kernel.org
Cc:	mst@...hat.com, Vladislav Yasevich <vyasevic@...hat.com>
Subject: Re: [RFC PATCH net-next 0/3] Extend macvtap with multiple qdiscs



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