search for: ndo_ops

...efault route for > everything else when it is available. > > The point is by the time you are done you will have rewritten pretty > much all the network device ops. With that being the case why add all > the code to virtio itself instead of just coming up with a brand new > set of ndo_ops that belong to this new device, and you could leave the > existing virtio code in place and save yourself a bunch of time by > just accessing it as an existing call as a separate netdev. When the BACKUP feature is enabled, we can simply disable most of these ndo ops that cannot be supported...

...get done, we'd resume > > the work for hiding lower netdev at that point. Think it would be the > > best to make everyone understand the big picture in advance before > > going too far. > > I think we should get the 3-netdev model integrated and add any additional > ndo_ops/ethool ops that we would like to support/migrate before looking into > hiding the lower netdevs. Once they are exposed, I don't think we'll be able to hide them - they will be a kernel ABI. Do you think everyone needs to hide the SRIOV device? Or that only some users need this? -- MS...

...t; the work for hiding lower netdev at that point. Think it would be the > > > > best to make everyone understand the big picture in advance before > > > > going too far. > > > I think we should get the 3-netdev model integrated and add any additional > > > ndo_ops/ethool ops that we would like to support/migrate before looking into > > > hiding the lower netdevs. > > Once they are exposed, I don't think we'll be able to hide them - > > they will be a kernel ABI. > > > > Do you think everyone needs to hide the SRIOV d...

...device should remember all configurations previously done and apply >> supporting ones to active device automatically when switching the >> datapath. >> > It should be possible to extend this patchset to support migration of > additional > settings by enabling additional ndo_ops and ethtool_ops on the upper dev > and propagating them down the lower devices and replaying the settings after > the VF is replugged after migration. Indeed. But your 3rd patch will collapse this merit of the 3-netdev into the former 2-netdev model - I hope it's just for demostrating th...

...els. 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 byp...

On 1/28/2018 9:35 AM, Alexander Duyck wrote: > On Fri, Jan 26, 2018 at 9:58 PM, Jakub Kicinski <kubakici at wp.pl> wrote: >> On Fri, 26 Jan 2018 21:33:01 -0800, Samudrala, Sridhar wrote: >>>>> 3 netdev model breaks this configuration starting with the creation >>>>> and naming of the 2 devices to udev needing to be aware of master and

...iguration. The upper > device should remember all configurations previously done and apply > supporting ones to active device automatically when switching the > datapath. > It should be possible to extend this patchset to support migration of additional settings? by enabling additional ndo_ops and ethtool_ops on the upper dev and propagating them down the lower devices and replaying the settings after the VF is replugged after migration. Thanks Sridhar

...iguration. The upper > device should remember all configurations previously done and apply > supporting ones to active device automatically when switching the > datapath. > It should be possible to extend this patchset to support migration of additional settings? by enabling additional ndo_ops and ethtool_ops on the upper dev and propagating them down the lower devices and replaying the settings after the VF is replugged after migration. Thanks Sridhar

...we'd resume >>> the work for hiding lower netdev at that point. Think it would be the >>> best to make everyone understand the big picture in advance before >>> going too far. >> I think we should get the 3-netdev model integrated and add any additional >> ndo_ops/ethool ops that we would like to support/migrate before looking into >> hiding the lower netdevs. > Once they are exposed, I don't think we'll be able to hide them - > they will be a kernel ABI. > > Do you think everyone needs to hide the SRIOV device? > Or that only so...

I ran this with a few folks offline and gathered some good feedbacks that I'd like to share thus revive the discussion. First of all, as illustrated in the reply below, cloud service providers require transparent live migration. Specifically, the main target of our case is to support SR-IOV live migration via kernel upgrade while keeping the userspace of old distros unmodified. If it's

...work for hiding lower netdev at that point. Think it would be the >>>>> best to make everyone understand the big picture in advance before >>>>> going too far. >>>> I think we should get the 3-netdev model integrated and add any additional >>>> ndo_ops/ethool ops that we would like to support/migrate before looking into >>>> hiding the lower netdevs. >>> Once they are exposed, I don't think we'll be able to hide them - >>> they will be a kernel ABI. >>> >>> Do you think everyone needs to hid...

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

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

...ches. Once all needed features get done, we'd resume > the work for hiding lower netdev at that point. Think it would be the > best to make everyone understand the big picture in advance before > going too far. I think we should get the 3-netdev model integrated and add any additional ndo_ops/ethool ops that we would like to support/migrate before looking into hiding the lower netdevs. > > Thanks, comments welcome. > > -Siwei > > > On Mon, Apr 9, 2018 at 11:48 PM, Siwei Liu <loseweigh at gmail.com> wrote: >> On Sun, Apr 8, 2018 at 9:32 AM, David Miller...

...he VF is expected to be the default route for everything else when it is available. The point is by the time you are done you will have rewritten pretty much all the network device ops. With that being the case why add all the code to virtio itself instead of just coming up with a brand new set of ndo_ops that belong to this new device, and you could leave the existing virtio code in place and save yourself a bunch of time by just accessing it as an existing call as a separate netdev. >>>>>> Also, from a user experience point of view, loading a virtio-net with >>>>>...

...ence(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_bypa...

On Fri, Feb 16, 2018 at 6:38 PM, Jakub Kicinski <kubakici at wp.pl> wrote: > On Fri, 16 Feb 2018 10:11:19 -0800, Sridhar Samudrala wrote: >> Ppatch 2 is in response to the community request for a 3 netdev >> solution. However, it creates some issues we'll get into in a moment. >> It extends virtio_net to use alternate datapath when available and >> registered.

On Fri, Feb 16, 2018 at 6:38 PM, Jakub Kicinski <kubakici at wp.pl> wrote: > On Fri, 16 Feb 2018 10:11:19 -0800, Sridhar Samudrala wrote: >> Ppatch 2 is in response to the community request for a 3 netdev >> solution. However, it creates some issues we'll get into in a moment. >> It extends virtio_net to use alternate datapath when available and >> registered.

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

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