Linux Virtualization - Apr 2018 - [RFC PATCH net-next v5 3/4] virtio_net: Extend virtio to use VF datapath when available

Tue, Apr 10, 2018 at 05:27:48PM CEST, sridhar.samudrala at intel.com
wrote:
>On 4/10/2018 8:22 AM, Jiri Pirko wrote:
>> Tue, Apr 10, 2018 at 05:13:40PM CEST, sridhar.samudrala at intel.com
wrote:
>> > On 4/10/2018 3:55 AM, Jiri Pirko wrote:
>> > > Mon, Apr 09, 2018 at 08:47:06PM CEST, sridhar.samudrala at
intel.com wrote:
>> > > > On 4/9/2018 1:07 AM, Jiri Pirko wrote:
>> > > > > Sat, Apr 07, 2018 at 12:59:14AM CEST,
sridhar.samudrala at intel.com wrote:
>> > > > > > On 4/6/2018 5:48 AM, Jiri Pirko wrote:
>> > > > > > > Thu, Apr 05, 2018 at 11:08:22PM CEST,
sridhar.samudrala at intel.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.

On Tue, Apr 10, 2018 at 8:43 AM, Jiri Pirko <jiri at resnulli.us>
wrote:
> Tue, Apr 10, 2018 at 05:27:48PM CEST, sridhar.samudrala at intel.com wrote:
>>On 4/10/2018 8:22 AM, Jiri Pirko wrote:
>>> Tue, Apr 10, 2018 at 05:13:40PM CEST, sridhar.samudrala at
intel.com wrote:
>>> > On 4/10/2018 3:55 AM, Jiri Pirko wrote:
>>> > > Mon, Apr 09, 2018 at 08:47:06PM CEST, sridhar.samudrala
at intel.com wrote:
>>> > > > On 4/9/2018 1:07 AM, Jiri Pirko wrote:
>>> > > > > Sat, Apr 07, 2018 at 12:59:14AM CEST,
sridhar.samudrala at intel.com wrote:
>>> > > > > > On 4/6/2018 5:48 AM, Jiri Pirko wrote:
>>> > > > > > > Thu, Apr 05, 2018 at 11:08:22PM CEST,
sridhar.samudrala at intel.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.
That's exactly the point why I need to hide the lower netdev slaves
and trying the align the naming of the bypass with where IP was
configured on the original netdev. The current 3-netdev model is not
"transparent" by any means.

-Siwei
> This only makes sense that the original netdev becomes the master for both
> netvsc and virtio_net.

On 4/10/2018 8:43 AM, Jiri Pirko wrote:
> Tue, Apr 10, 2018 at 05:27:48PM CEST, sridhar.samudrala at intel.com wrote:
>> On 4/10/2018 8:22 AM, Jiri Pirko wrote:
>>> Tue, Apr 10, 2018 at 05:13:40PM CEST, sridhar.samudrala at
intel.com wrote:
>>>> On 4/10/2018 3:55 AM, Jiri Pirko wrote:
>>>>> Mon, Apr 09, 2018 at 08:47:06PM CEST, sridhar.samudrala at
intel.com wrote:
>>>>>> On 4/9/2018 1:07 AM, Jiri Pirko wrote:
>>>>>>> Sat, Apr 07, 2018 at 12:59:14AM CEST,
sridhar.samudrala at intel.com wrote:
>>>>>>>> On 4/6/2018 5:48 AM, Jiri Pirko wrote:
>>>>>>>>> Thu, Apr 05, 2018 at 11:08:22PM CEST,
sridhar.samudrala at intel.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.
So the userspace network configuration doesn't need to change.

Tue, Apr 10, 2018 at 05:59:02PM CEST, sridhar.samudrala at intel.com
wrote:
>On 4/10/2018 8:43 AM, Jiri Pirko wrote:
>> Tue, Apr 10, 2018 at 05:27:48PM CEST, sridhar.samudrala at intel.com
wrote:
>> > On 4/10/2018 8:22 AM, Jiri Pirko wrote:
>> > > Tue, Apr 10, 2018 at 05:13:40PM CEST, sridhar.samudrala at
intel.com wrote:
>> > > > On 4/10/2018 3:55 AM, Jiri Pirko wrote:
>> > > > > Mon, Apr 09, 2018 at 08:47:06PM CEST,
sridhar.samudrala at intel.com wrote:
>> > > > > > On 4/9/2018 1:07 AM, Jiri Pirko wrote:
>> > > > > > > Sat, Apr 07, 2018 at 12:59:14AM CEST,
sridhar.samudrala at intel.com wrote:
>> > > > > > > > On 4/6/2018 5:48 AM, Jiri Pirko
wrote:
>> > > > > > > > > Thu, Apr 05, 2018 at 11:08:22PM
CEST, sridhar.samudrala at intel.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"?

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