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

2018-04-11 Thread Jiri Pirko 
Wed, Apr 11, 2018 at 04:45:07PM CEST, m...@redhat.com wrote:
>On Wed, Apr 11, 2018 at 10:03:32AM +0200, Jiri Pirko wrote:
>> Wed, Apr 11, 2018 at 08:24:43AM CEST, sridhar.samudr...@intel.com wrote:
>> >On 4/10/2018 11:03 PM, Jiri Pirko wrote:
>> >> Tue, Apr 10, 2018 at 05:59:02PM CEST, sridhar.samudr...@intel.com wrote:
>> >> > On 4/10/2018 8:43 AM, Jiri Pirko wrote:
>> >> > > Tue, Apr 10, 2018 at 05:27:48PM CEST, sridhar.samudr...@intel.com 
>> >> > > wrote:
>> >> > > > On 4/10/2018 8:22 AM, Jiri Pirko wrote:
>> >> > > > > Tue, Apr 10, 2018 at 05:13:40PM CEST, sridhar.samudr...@intel.com 
>> >> > > > > wrote:
>> >> > > > > > On 4/10/2018 3:55 AM, Jiri Pirko wrote:
>> >> > > > > > > Mon, Apr 09, 2018 at 08:47:06PM CEST, 
>> >> > > > > > > sridhar.samudr...@intel.com wrote:
>> >> > > > > > > > On 4/9/2018 1:07 AM, Jiri Pirko wrote:
>> >> > > > > > > > > Sat, Apr 07, 2018 at 12:59:14AM CEST, 
>> >> > > > > > > > > sridhar.samudr...@intel.com wrote:
>> >> > > > > > > > > > On 4/6/2018 5:48 AM, Jiri Pirko wrote:
>> >> > > > > > > > > > > Thu, Apr 05, 2018 at 11:08:22PM CEST, 
>> >> > > > > > > > > > > sridhar.samudr...@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
>> >> > > >   / \
>> >>

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

2018-04-11 Thread Michael S. Tsirkin 
On Wed, Apr 11, 2018 at 10:03:32AM +0200, Jiri Pirko wrote:
> Wed, Apr 11, 2018 at 08:24:43AM CEST, sridhar.samudr...@intel.com wrote:
> >On 4/10/2018 11:03 PM, Jiri Pirko wrote:
> >> Tue, Apr 10, 2018 at 05:59:02PM CEST, sridhar.samudr...@intel.com wrote:
> >> > On 4/10/2018 8:43 AM, Jiri Pirko wrote:
> >> > > Tue, Apr 10, 2018 at 05:27:48PM CEST, sridhar.samudr...@intel.com 
> >> > > wrote:
> >> > > > On 4/10/2018 8:22 AM, Jiri Pirko wrote:
> >> > > > > Tue, Apr 10, 2018 at 05:13:40PM CEST, sridhar.samudr...@intel.com 
> >> > > > > wrote:
> >> > > > > > On 4/10/2018 3:55 AM, Jiri Pirko wrote:
> >> > > > > > > Mon, Apr 09, 2018 at 08:47:06PM CEST, 
> >> > > > > > > sridhar.samudr...@intel.com wrote:
> >> > > > > > > > On 4/9/2018 1:07 AM, Jiri Pirko wrote:
> >> > > > > > > > > Sat, Apr 07, 2018 at 12:59:14AM CEST, 
> >> > > > > > > > > sridhar.samudr...@intel.com wrote:
> >> > > > > > > > > > On 4/6/2018 5:48 AM, Jiri Pirko wrote:
> >> > > > > > > > > > > Thu, Apr 05, 2018 at 11:08:22PM CEST, 
> >> > > > > > > > > > > sridhar.samudr...@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

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

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

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

2018-04-11 Thread Samudrala, Sridhar 

On 4/10/2018 11:03 PM, Jiri Pirko wrote:

Tue, Apr 10, 2018 at 05:59:02PM CEST, sridhar.samudr...@intel.com wrote:

On 4/10/2018 8:43 AM, Jiri Pirko wrote:

Tue, Apr 10, 2018 at 05:27:48PM CEST, sridhar.samudr...@intel.com wrote:

On 4/10/2018 8:22 AM, Jiri Pirko wrote:

Tue, Apr 10, 2018 at 05:13:40PM CEST, sridhar.samudr...@intel.com wrote:

On 4/10/2018 3:55 AM, Jiri Pirko wrote:

Mon, Apr 09, 2018 at 08:47:06PM CEST, sridhar.samudr...@intel.com wrote:

On 4/9/2018 1:07 AM, Jiri Pirko wrote:

Sat, Apr 07, 2018 at 12:59:14AM CEST, sridhar.samudr...@intel.com wrote:

On 4/6/2018 5:48 AM, Jiri Pirko wrote:

Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudr...@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"?


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.

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

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

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

2018-04-10 Thread Samudrala, Sridhar 

On 4/10/2018 8:43 AM, Jiri Pirko wrote:

Tue, Apr 10, 2018 at 05:27:48PM CEST, sridhar.samudr...@intel.com wrote:

On 4/10/2018 8:22 AM, Jiri Pirko wrote:

Tue, Apr 10, 2018 at 05:13:40PM CEST, sridhar.samudr...@intel.com wrote:

On 4/10/2018 3:55 AM, Jiri Pirko wrote:

Mon, Apr 09, 2018 at 08:47:06PM CEST, sridhar.samudr...@intel.com wrote:

On 4/9/2018 1:07 AM, Jiri Pirko wrote:

Sat, Apr 07, 2018 at 12:59:14AM CEST, sridhar.samudr...@intel.com wrote:

On 4/6/2018 5:48 AM, Jiri Pirko wrote:

Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudr...@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.

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

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

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

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

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

2018-04-10 Thread Samudrala, Sridhar 

On 4/10/2018 8:22 AM, Jiri Pirko wrote:

Tue, Apr 10, 2018 at 05:13:40PM CEST, sridhar.samudr...@intel.com wrote:

On 4/10/2018 3:55 AM, Jiri Pirko wrote:

Mon, Apr 09, 2018 at 08:47:06PM CEST, sridhar.samudr...@intel.com wrote:

On 4/9/2018 1:07 AM, Jiri Pirko wrote:

Sat, Apr 07, 2018 at 12:59:14AM CEST, sridhar.samudr...@intel.com wrote:

On 4/6/2018 5:48 AM, Jiri Pirko wrote:

Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudr...@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)

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

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

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

2018-04-10 Thread Samudrala, Sridhar 

On 4/10/2018 3:55 AM, Jiri Pirko wrote:

Mon, Apr 09, 2018 at 08:47:06PM CEST, sridhar.samudr...@intel.com wrote:

On 4/9/2018 1:07 AM, Jiri Pirko wrote:

Sat, Apr 07, 2018 at 12:59:14AM CEST, sridhar.samudr...@intel.com wrote:

On 4/6/2018 5:48 AM, Jiri Pirko wrote:

Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudr...@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

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

2018-04-10 Thread Jiri Pirko 
Mon, Apr 09, 2018 at 08:47:06PM CEST, sridhar.samudr...@intel.com wrote:
>On 4/9/2018 1:07 AM, Jiri Pirko wrote:
>> Sat, Apr 07, 2018 at 12:59:14AM CEST, sridhar.samudr...@intel.com wrote:
>> > On 4/6/2018 5:48 AM, Jiri Pirko wrote:
>> > > Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudr...@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?

[...]

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

2018-04-09 Thread Samudrala, Sridhar 

On 4/9/2018 1:07 AM, Jiri Pirko wrote:

Sat, Apr 07, 2018 at 12:59:14AM CEST, sridhar.samudr...@intel.com wrote:

On 4/6/2018 5:48 AM, Jiri Pirko wrote:

Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudr...@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.

In the 2 netdev model, backup_slave acts as bypass_master and the bypass module 
doesn't
have access to netdev_priv of the backup_slave.

Once i moved all the ndo_ops of the master netdev to bypass module, i realized 
that we can
move the create/destroy of the upper netdev also to bypass.c.
That way the changes to virtio_net become very minimal.

With these updates, bypass module now supports both the models by exporting 2 
sets of
functions.
3 netdev:
   int bypass_master_create(struct net_device *backup_netdev,
struct bypass_master **pbypass_master);
   void bypass_master_destroy(struct bypass_master *bypass_master);


2 netdev:
   int bypass_master_register(struct net_device *backup_netdev, struct 
bypass_ops *ops,
  struct bypass_master **pbypass_master);
   void bypass_master_unregister(struct bypass_master *bypass_master);

Will send the next revision in a day or two.

Thanks
Sridhar

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

2018-04-09 Thread Jiri Pirko 
Sat, Apr 07, 2018 at 12:59:14AM CEST, sridhar.samudr...@intel.com wrote:
>On 4/6/2018 5:48 AM, Jiri Pirko wrote:
>> Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudr...@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?

Thanks!

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

2018-04-06 Thread Samudrala, Sridhar 

On 4/6/2018 5:48 AM, Jiri Pirko wrote:

Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudr...@intel.com wrote:






+
+static void virtnet_bypass_set_rx_mode(struct net_device *dev)
+{
+   struct virtnet_bypass_info *vbi = netdev_priv(dev);
+   struct net_device *child_netdev;
+
+   rcu_read_lock();
+
+   child_netdev = rcu_dereference(vbi->active_netdev);
+   if (child_netdev) {
+   dev_uc_sync_multiple(child_netdev, dev);
+   dev_mc_sync_multiple(child_netdev, dev);
+   }
+
+   child_netdev = rcu_dereference(vbi->backup_netdev);
+   if (child_netdev) {
+   dev_uc_sync_multiple(child_netdev, dev);
+   dev_mc_sync_multiple(child_netdev, dev);
+   }
+
+   rcu_read_unlock();
+}

This should be moved to bypass module.


Sure. All these bypass ndo_ops can be moved to bypass module and any
paravirtual driver that want to go with 3 netdev model can reuse these 
functions.






+
+static const struct net_device_ops virtnet_bypass_netdev_ops = {
+   .ndo_open   = virtnet_bypass_open,
+   .ndo_stop   = virtnet_bypass_close,
+   .ndo_start_xmit = virtnet_bypass_start_xmit,
+   .ndo_select_queue   = virtnet_bypass_select_queue,
+   .ndo_get_stats64= virtnet_bypass_get_stats,
+   .ndo_change_mtu = virtnet_bypass_change_mtu,
+   .ndo_set_rx_mode= virtnet_bypass_set_rx_mode,
+   .ndo_validate_addr  = eth_validate_addr,
+   .ndo_features_check = passthru_features_check,
+};
+
+static int
+virtnet_bypass_ethtool_get_link_ksettings(struct net_device *dev,
+ struct ethtool_link_ksettings *cmd)
+{
+   struct virtnet_bypass_info *vbi = netdev_priv(dev);
+   struct net_device *child_netdev;
+
+   child_netdev = rtnl_dereference(vbi->active_netdev);
+   if (!child_netdev || !virtnet_bypass_xmit_ready(child_netdev)) {
+   child_netdev = rtnl_dereference(vbi->backup_netdev);
+   if (!child_netdev || !virtnet_bypass_xmit_ready(child_netdev)) {
+   cmd->base.duplex = DUPLEX_UNKNOWN;
+   cmd->base.port = PORT_OTHER;
+   cmd->base.speed = SPEED_UNKNOWN;
+
+   return 0;
+   }
+   }
+
+   return __ethtool_get_link_ksettings(child_netdev, cmd);
+}
+
+#define BYPASS_DRV_NAME "virtnet_bypass"
+#define BYPASS_DRV_VERSION "0.1"
+
+static void virtnet_bypass_ethtool_get_drvinfo(struct net_device *dev,
+  struct ethtool_drvinfo *drvinfo)
+{
+   strlcpy(drvinfo->driver, BYPASS_DRV_NAME, sizeof(drvinfo->driver));
+   strlcpy(drvinfo->version, BYPASS_DRV_VERSION, sizeof(drvinfo->version));
+}
+
+static const struct ethtool_ops virtnet_bypass_ethtool_ops = {
+   .get_drvinfo= virtnet_bypass_ethtool_get_drvinfo,
+   .get_link   = ethtool_op_get_link,
+   .get_link_ksettings = virtnet_bypass_ethtool_get_link_ksettings,
+};
+
+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.





The active/backup terminology is quite confusing. From the bonding world
that means active is the one which is currently used for tx of the
packets. And it depends on link and other things what netdev is declared
active. However here, it is different. Backup is always the virtio_net
instance even when it is active. Odd. Please change the terminology.
For "active" I suggest to use name "stolen".


I am not too happy with 'stolen' name. Will see if i can come up with a
better name.




*** Also, the 2 slave netdev pointers should be stored in the bypass
module instance, not in the drivers.


Will move virtnet_bypass_info struct to bypass.h






+   return -EEXIST;
+   }
+
+   dev_hold(child_netdev);
+
+   if (backup) {
+

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

2018-04-06 Thread Jiri Pirko 
Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudr...@intel.com wrote:
>This patch enables virtio_net to switch over to a VF datapath when a VF
>netdev is present with the same MAC address. It allows live migration
>of a VM with a direct attached VF without the need to setup a bond/team
>between a VF and virtio net device in the guest.
>
>The hypervisor needs to enable only one datapath at any time so that
>packets don't get looped back to the VM over the other datapath. When a VF
>is plugged, the virtio datapath link state can be marked as down. The
>hypervisor needs to unplug the VF device from the guest on the source host
>and reset the MAC filter of the VF to initiate failover of datapath to
>virtio before starting the migration. After the migration is completed,
>the destination hypervisor sets the MAC filter on the VF and plugs it back
>to the guest to switch over to VF datapath.
>
>When BACKUP feature is enabled, an additional netdev(bypass netdev) is
>created that acts as a master device and tracks the state of the 2 lower
>netdevs. The original virtio_net netdev is marked as 'backup' netdev and a
>passthru device with the same MAC is registered as 'active' netdev.
>
>This patch is based on the discussion initiated by Jesse on this thread.
>https://marc.info/?l=linux-virtualization=151189725224231=2
>
>Signed-off-by: Sridhar Samudrala 
>---
> drivers/net/Kconfig  |   1 +
> drivers/net/virtio_net.c | 612 ++-
> 2 files changed, 612 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
>index 891846655000..9e2cf61fd1c1 100644
>--- a/drivers/net/Kconfig
>+++ b/drivers/net/Kconfig
>@@ -331,6 +331,7 @@ config VETH
> config VIRTIO_NET
>   tristate "Virtio network driver"
>   depends on VIRTIO
>+  depends on MAY_USE_BYPASS
>   ---help---
> This is the virtual network driver for virtio.  It can be used with
> QEMU based VMMs (like KVM or Xen).  Say Y or M.
>diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>index befb5944f3fd..86b2f8f2947d 100644
>--- a/drivers/net/virtio_net.c
>+++ b/drivers/net/virtio_net.c
>@@ -30,8 +30,11 @@
> #include 
> #include 
> #include 
>+#include 
>+#include 
> #include 
> #include 
>+#include 
> 
> static int napi_weight = NAPI_POLL_WEIGHT;
> module_param(napi_weight, int, 0444);
>@@ -206,6 +209,9 @@ struct virtnet_info {
>   u32 speed;
> 
>   unsigned long guest_offloads;
>+
>+  /* upper netdev created when BACKUP feature enabled */
>+  struct net_device __rcu *bypass_netdev;
> };
> 
> struct padded_vnet_hdr {
>@@ -2275,6 +2281,22 @@ static int virtnet_xdp(struct net_device *dev, struct 
>netdev_bpf *xdp)
>   }
> }
> 
>+static int virtnet_get_phys_port_name(struct net_device *dev, char *buf,
>+size_t len)
>+{
>+  struct virtnet_info *vi = netdev_priv(dev);
>+  int ret;
>+
>+  if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_BACKUP))
>+  return -EOPNOTSUPP;
>+
>+  ret = snprintf(buf, len, "_bkup");
>+  if (ret >= len)
>+  return -EOPNOTSUPP;
>+
>+  return 0;
>+}
>+
> static const struct net_device_ops virtnet_netdev = {
>   .ndo_open= virtnet_open,
>   .ndo_stop= virtnet_close,
>@@ -2292,6 +2314,7 @@ static const struct net_device_ops virtnet_netdev = {
>   .ndo_xdp_xmit   = virtnet_xdp_xmit,
>   .ndo_xdp_flush  = virtnet_xdp_flush,
>   .ndo_features_check = passthru_features_check,
>+  .ndo_get_phys_port_name = virtnet_get_phys_port_name,
> };
> 
> static void virtnet_config_changed_work(struct work_struct *work)
>@@ -2689,6 +2712,576 @@ static int virtnet_validate(struct virtio_device *vdev)
>   return 0;
> }
> 
>+/* START of functions supporting VIRTIO_NET_F_BACKUP feature.
>+ * When BACKUP feature is enabled, an additional netdev(bypass netdev)
>+ * is created that acts as a master device and tracks the state of the
>+ * 2 lower netdevs. The original virtio_net netdev is registered as
>+ * 'backup' netdev and a passthru device with the same MAC is registered
>+ * as 'active' netdev.
>+ */
>+
>+/* bypass state maintained when BACKUP feature is enabled */
>+struct virtnet_bypass_info {
>+  /* passthru netdev with same MAC */
>+  struct net_device __rcu *active_netdev;
>+
>+  /* virtio_net netdev */
>+  struct net_device __rcu *backup_netdev;
>+
>+  /* active netdev stats */
>+  struct rtnl_link_stats64 active_stats;
>+
>+  /* backup netdev stats */
>+  struct rtnl_link_stats64 backup_stats;
>+
>+  /* aggregated stats */
>+  struct rtnl_link_stats64 bypass_stats;
>+
>+  /* spinlock while updating stats */
>+  spinlock_t stats_lock;
>+};
>+
>+static int virtnet_bypass_open(struct net_device *dev)
>+{
>+  struct virtnet_bypass_info *vbi = netdev_priv(dev);
>+  struct net_device *active_netdev,

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

2018-04-05 Thread Sridhar Samudrala 
This patch enables virtio_net to switch over to a VF datapath when a VF
netdev is present with the same MAC address. It allows live migration
of a VM with a direct attached VF without the need to setup a bond/team
between a VF and virtio net device in the guest.

The hypervisor needs to enable only one datapath at any time so that
packets don't get looped back to the VM over the other datapath. When a VF
is plugged, the virtio datapath link state can be marked as down. The
hypervisor needs to unplug the VF device from the guest on the source host
and reset the MAC filter of the VF to initiate failover of datapath to
virtio before starting the migration. After the migration is completed,
the destination hypervisor sets the MAC filter on the VF and plugs it back
to the guest to switch over to VF datapath.

When BACKUP feature is enabled, an additional netdev(bypass netdev) is
created that acts as a master device and tracks the state of the 2 lower
netdevs. The original virtio_net netdev is marked as 'backup' netdev and a
passthru device with the same MAC is registered as 'active' netdev.

This patch is based on the discussion initiated by Jesse on this thread.
https://marc.info/?l=linux-virtualization=151189725224231=2

Signed-off-by: Sridhar Samudrala 
---
 drivers/net/Kconfig  |   1 +
 drivers/net/virtio_net.c | 612 ++-
 2 files changed, 612 insertions(+), 1 deletion(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 891846655000..9e2cf61fd1c1 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -331,6 +331,7 @@ config VETH
 config VIRTIO_NET
tristate "Virtio network driver"
depends on VIRTIO
+   depends on MAY_USE_BYPASS
---help---
  This is the virtual network driver for virtio.  It can be used with
  QEMU based VMMs (like KVM or Xen).  Say Y or M.
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index befb5944f3fd..86b2f8f2947d 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -30,8 +30,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
+#include 
 
 static int napi_weight = NAPI_POLL_WEIGHT;
 module_param(napi_weight, int, 0444);
@@ -206,6 +209,9 @@ struct virtnet_info {
u32 speed;
 
unsigned long guest_offloads;
+
+   /* upper netdev created when BACKUP feature enabled */
+   struct net_device __rcu *bypass_netdev;
 };
 
 struct padded_vnet_hdr {
@@ -2275,6 +2281,22 @@ static int virtnet_xdp(struct net_device *dev, struct 
netdev_bpf *xdp)
}
 }
 
+static int virtnet_get_phys_port_name(struct net_device *dev, char *buf,
+ size_t len)
+{
+   struct virtnet_info *vi = netdev_priv(dev);
+   int ret;
+
+   if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_BACKUP))
+   return -EOPNOTSUPP;
+
+   ret = snprintf(buf, len, "_bkup");
+   if (ret >= len)
+   return -EOPNOTSUPP;
+
+   return 0;
+}
+
 static const struct net_device_ops virtnet_netdev = {
.ndo_open= virtnet_open,
.ndo_stop= virtnet_close,
@@ -2292,6 +2314,7 @@ static const struct net_device_ops virtnet_netdev = {
.ndo_xdp_xmit   = virtnet_xdp_xmit,
.ndo_xdp_flush  = virtnet_xdp_flush,
.ndo_features_check = passthru_features_check,
+   .ndo_get_phys_port_name = virtnet_get_phys_port_name,
 };
 
 static void virtnet_config_changed_work(struct work_struct *work)
@@ -2689,6 +2712,576 @@ static int virtnet_validate(struct virtio_device *vdev)
return 0;
 }
 
+/* START of functions supporting VIRTIO_NET_F_BACKUP feature.
+ * When BACKUP feature is enabled, an additional netdev(bypass netdev)
+ * is created that acts as a master device and tracks the state of the
+ * 2 lower netdevs. The original virtio_net netdev is registered as
+ * 'backup' netdev and a passthru device with the same MAC is registered
+ * as 'active' netdev.
+ */
+
+/* bypass state maintained when BACKUP feature is enabled */
+struct virtnet_bypass_info {
+   /* passthru netdev with same MAC */
+   struct net_device __rcu *active_netdev;
+
+   /* virtio_net netdev */
+   struct net_device __rcu *backup_netdev;
+
+   /* active netdev stats */
+   struct rtnl_link_stats64 active_stats;
+
+   /* backup netdev stats */
+   struct rtnl_link_stats64 backup_stats;
+
+   /* aggregated stats */
+   struct rtnl_link_stats64 bypass_stats;
+
+   /* spinlock while updating stats */
+   spinlock_t stats_lock;
+};
+
+static int virtnet_bypass_open(struct net_device *dev)
+{
+   struct virtnet_bypass_info *vbi = netdev_priv(dev);
+   struct net_device *active_netdev, *backup_netdev;
+   int err;
+
+   netif_carrier_off(dev);
+   netif_tx_wake_all_queues(dev);
+
+   active_netdev = rtnl_dereference(vbi->active_netdev);