similar to: [RFC PATCH] virtio_net: Extend virtio to use VF datapath when available

This patch series extends virtio_net to take over VF datapath by simulating a transparent bond without creating any additional netdev. I understand that there are some comments suggesting an alternate model that is based on 3 driver model(virtio_net, VF driver, a new driver virt_bond that acts as a master to virtio_net and VF). Would like to get some feedback on the right way to solve the live

On Mon, Dec 18, 2017 at 04:40:36PM -0800, Sridhar Samudrala wrote: > This patch enables virtio to switch over to a VF datapath when a VF netdev > is present with the same MAC address. I prefer saying "a passthrough device" here. Does not have to be a VF at all. > It allows live migration of a VM > with a direct attached VF without the need to setup a bond/team between a

This patch series enables virtio 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 unplug the VF device from the guest on the source host and reset the MAC filter of the VF to initiate

This patch series enables virtio 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 unplug the VF device from the guest on the source host and reset the MAC filter of the VF to initiate

This patch enables virtio_net to switch over to a VF datapath when a VF netdev is present with the same MAC address. The VF datapath is only used for unicast traffic. Broadcasts/multicasts go via virtio datapath so that east-west broadcasts don't use the PCI bandwidth. 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

First off, as mentioned in another thread, the model of stacking up virt-bond functionality over virtio seems a wrong direction to me. Essentially the migration process would need to carry over all guest side configurations previously done on the VF/PT and get them moved to the new device being it virtio or VF/PT. Without the help of a new upper layer bond driver that enslaves virtio and VF/PT

First off, as mentioned in another thread, the model of stacking up virt-bond functionality over virtio seems a wrong direction to me. Essentially the migration process would need to carry over all guest side configurations previously done on the VF/PT and get them moved to the new device being it virtio or VF/PT. Without the help of a new upper layer bond driver that enslaves virtio and VF/PT

The main motivation for this patch is to enable cloud service providers to provide an accelerated datapath to virtio-net enabled VMs in a transparent manner with no/minimal guest userspace changes. This also enables hypervisor controlled live migration to be supported with VMs that have direct attached SR-IOV VF devices. Patch 1 introduces a new feature bit VIRTIO_NET_F_STANDBY that can be used

Use the registration/notification framework supported by the generic failover infrastructure. Signed-off-by: Sridhar Samudrala <sridhar.samudrala at intel.com> --- drivers/net/hyperv/Kconfig | 1 + drivers/net/hyperv/hyperv_net.h | 2 + drivers/net/hyperv/netvsc_drv.c | 208 ++++++++++------------------------------ 3 files changed, 55 insertions(+), 156 deletions(-) diff --git

Use the registration/notification framework supported by the generic bypass infrastructure. Signed-off-by: Sridhar Samudrala <sridhar.samudrala at intel.com> --- drivers/net/hyperv/Kconfig | 1 + drivers/net/hyperv/hyperv_net.h | 2 + drivers/net/hyperv/netvsc_drv.c | 208 ++++++++++------------------------------ 3 files changed, 55 insertions(+), 156 deletions(-) diff --git

Use the registration/notification framework supported by the generic failover infrastructure. Signed-off-by: Sridhar Samudrala <sridhar.samudrala at intel.com> --- drivers/net/hyperv/Kconfig | 1 + drivers/net/hyperv/hyperv_net.h | 2 + drivers/net/hyperv/netvsc_drv.c | 222 +++++++++++----------------------------- 3 files changed, 60 insertions(+), 165 deletions(-) diff --git

The main motivation for this patch is to enable cloud service providers to provide an accelerated datapath to virtio-net enabled VMs in a transparent manner with no/minimal guest userspace changes. This also enables hypervisor controlled live migration to be supported with VMs that have direct attached SR-IOV VF devices. Patch 1 introduces a new feature bit VIRTIO_NET_F_BACKUP that can be used

Use the registration/notification framework supported by the generic failover infrastructure. Signed-off-by: Sridhar Samudrala <sridhar.samudrala at intel.com> --- drivers/net/hyperv/Kconfig | 1 + drivers/net/hyperv/hyperv_net.h | 2 + drivers/net/hyperv/netvsc_drv.c | 133 +++++++--------------------------------- 3 files changed, 25 insertions(+), 111 deletions(-) diff --git

Use the registration/notification framework supported by the generic failover infrastructure. Signed-off-by: Sridhar Samudrala <sridhar.samudrala at intel.com> --- drivers/net/hyperv/Kconfig | 1 + drivers/net/hyperv/hyperv_net.h | 2 + drivers/net/hyperv/netvsc_drv.c | 134 +++++++--------------------------------- 3 files changed, 26 insertions(+), 111 deletions(-) diff --git

Use the registration/notification framework supported by the generic failover infrastructure. Signed-off-by: Sridhar Samudrala <sridhar.samudrala at intel.com> --- drivers/net/hyperv/Kconfig | 1 + drivers/net/hyperv/hyperv_net.h | 2 + drivers/net/hyperv/netvsc_drv.c | 134 +++++++--------------------------------- 3 files changed, 26 insertions(+), 111 deletions(-) diff --git

The main motivation for this patch is to enable cloud service providers to provide an accelerated datapath to virtio-net enabled VMs in a transparent manner with no/minimal guest userspace changes. This also enables hypervisor controlled live migration to be supported with VMs that have direct attached SR-IOV VF devices. Patch 1 introduces a new feature bit VIRTIO_NET_F_BACKUP that can be used

The main motivation for this patch is to enable cloud service providers to provide an accelerated datapath to virtio-net enabled VMs in a transparent manner with no/minimal guest userspace changes. This also enables hypervisor controlled live migration to be supported with VMs that have direct attached SR-IOV VF devices. Patch 1 introduces a failover module that provides a generic interface for

This is another update based on feedback from MST and Stephen on the last patchset. Hopefully this series can be integrated and any further enhancements can be made on top of this patchset. v8: - Made the failover managment routines more robust by updating the feature bits/other fields in the failover netdev when slave netdevs are registered/unregistered. (mst) - added support for handling

The main motivation for this patch is to enable cloud service providers to provide an accelerated datapath to virtio-net enabled VMs in a transparent manner with no/minimal guest userspace changes. This also enables hypervisor controlled live migration to be supported with VMs that have direct attached SR-IOV VF devices. Patch 1 introduces a new feature bit VIRTIO_NET_F_STANDBY that can be used

The main motivation for this patch is to enable cloud service providers to provide an accelerated datapath to virtio-net enabled VMs in a transparent manner with no/minimal guest userspace changes. This also enables hypervisor controlled live migration to be supported with VMs that have direct attached SR-IOV VF devices. Patch 1 introduces a failover module that provides a generic interface for