netdev - Re: [RFC PATCH net-next v5 3/4] virtio_net: Extend virtio to use VF datapath when available

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <5d56e572-24f1-745d-49ae-c2dada5db03c@intel.com>
Date:   Tue, 10 Apr 2018 23:24:43 -0700
From:   "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     mst@...hat.com, stephen@...workplumber.org, davem@...emloft.net,
        netdev@...r.kernel.org, virtualization@...ts.linux-foundation.org,
        virtio-dev@...ts.oasis-open.org, jesse.brandeburg@...el.com,
        alexander.h.duyck@...el.com, kubakici@...pl, jasowang@...hat.com,
        loseweigh@...il.com
Subject: Re: [RFC PATCH net-next v5 3/4] virtio_net: Extend virtio to use VF
 datapath when available

On 4/10/2018 11:03 PM, Jiri Pirko wrote:
> Tue, Apr 10, 2018 at 05:59:02PM CEST, sridhar.samudrala@...el.com wrote:
>> On 4/10/2018 8:43 AM, Jiri Pirko wrote:
>>> Tue, Apr 10, 2018 at 05:27:48PM CEST, sridhar.samudrala@...el.com wrote:
>>>> On 4/10/2018 8:22 AM, Jiri Pirko wrote:
>>>>> Tue, Apr 10, 2018 at 05:13:40PM CEST, sridhar.samudrala@...el.com wrote:
>>>>>> On 4/10/2018 3:55 AM, Jiri Pirko wrote:
>>>>>>> Mon, Apr 09, 2018 at 08:47:06PM CEST, sridhar.samudrala@...el.com wrote:
>>>>>>>> On 4/9/2018 1:07 AM, Jiri Pirko wrote:
>>>>>>>>> Sat, Apr 07, 2018 at 12:59:14AM CEST, sridhar.samudrala@...el.com wrote:
>>>>>>>>>> On 4/6/2018 5:48 AM, Jiri Pirko wrote:
>>>>>>>>>>> Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudrala@...el.com wrote:
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>>>>> +static int virtnet_bypass_join_child(struct net_device *bypass_netdev,
>>>>>>>>>>>> +				     struct net_device *child_netdev)
>>>>>>>>>>>> +{
>>>>>>>>>>>> +	struct virtnet_bypass_info *vbi;
>>>>>>>>>>>> +	bool backup;
>>>>>>>>>>>> +
>>>>>>>>>>>> +	vbi = netdev_priv(bypass_netdev);
>>>>>>>>>>>> +	backup = (child_netdev->dev.parent == bypass_netdev->dev.parent);
>>>>>>>>>>>> +	if (backup ? rtnl_dereference(vbi->backup_netdev) :
>>>>>>>>>>>> +			rtnl_dereference(vbi->active_netdev)) {
>>>>>>>>>>>> +		netdev_info(bypass_netdev,
>>>>>>>>>>>> +			    "%s attempting to join bypass dev when %s already present\n",
>>>>>>>>>>>> +			    child_netdev->name, backup ? "backup" : "active");
>>>>>>>>>>> Bypass module should check if there is already some other netdev
>>>>>>>>>>> enslaved and refuse right there.
>>>>>>>>>> This will work for virtio-net with 3 netdev model, but this check has to be done by netvsc
>>>>>>>>>> as its bypass_netdev is same as the backup_netdev.
>>>>>>>>>> Will add a flag while registering with the bypass module to indicate if the driver is doing
>>>>>>>>>> a 2 netdev or 3 netdev model and based on that flag this check can be done in bypass module
>>>>>>>>>> for 3 netdev scenario.
>>>>>>>>> Just let me undestand it clearly. What I expect the difference would be
>>>>>>>>> between 2netdev and3 netdev model is this:
>>>>>>>>> 2netdev:
>>>>>>>>>        bypass_master
>>>>>>>>>           /
>>>>>>>>>          /
>>>>>>>>> VF_slave
>>>>>>>>>
>>>>>>>>> 3netdev:
>>>>>>>>>        bypass_master
>>>>>>>>>           /     \
>>>>>>>>>          /       \
>>>>>>>>> VF_slave   backup_slave
>>>>>>>>>
>>>>>>>>> Is that correct? If not, how does it look like?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Looks correct.
>>>>>>>> VF_slave and backup_slave are the original netdevs and are present in both the models.
>>>>>>>> In the 3 netdev model, bypass_master netdev is created and VF_slave and backup_slave are
>>>>>>>> marked as the 2 slaves of this new netdev.
>>>>>>> You say it looks correct and in another sentence you provide completely
>>>>>>> different description. Could you please look again?
>>>>>>>
>>>>>> To be exact, 2 netdev model with netvsc looks like this.
>>>>>>
>>>>>>       netvsc_netdev
>>>>>>         /
>>>>>>        /
>>>>>> VF_slave
>>>>>>
>>>>>> With virtio_net, 3 netdev model
>>>>>>
>>>>>>     bypass_netdev
>>>>>>         /     \
>>>>>>        /       \
>>>>>> VF_slave   virtio_net netdev
>>>>> Could you also mark the original netdev which is there now? is it
>>>>> bypass_netdev or virtio_net_netdev ?
>>>> bypass_netdev
>>>>       /     \
>>>>      /       \
>>>> VF_slave   virtio_net netdev (original)
>>> That does not make sense.
>>> 1) You diverge from the behaviour of the netvsc, where the original
>>>      netdev is a master of the VF
>>> 2) If the original netdev is a slave, you cannot have any IP address
>>>      configured on it (well you could, but the rx_handler would eat every
>>>      incoming packet). So you will break the user bacause he would have to
>>>      move the configuration to the new master device.
>>> This only makes sense that the original netdev becomes the master for both
>>> netvsc and virtio_net.
>> Forgot to mention that bypass_netdev takes over the name of the original
>> netdev and
>> virtio_net netdev will get the backup name.
> What do you mean by "name"?

bypass_netdev also is associated with the same pci device as the original virtio_net
netdev via SET_NETDEV_DEV().  Also, we added ndo_get_phys_port_name() to virtio_net
that will return _bkup when BACKUP feature is enabled.

So for ex: if virtio_net inteface was getting 'ens12' as the name assigned by udev
without BACKUP feature,  when BACKUP feature is enabled,  the  bypass_netdev will be
named 'ens12' and the original virtio_net will get named as ens12n_bkup.


>
>> So the userspace network configuration doesn't need to change.
>>
>>