similar to: [PATCH net-next v9 2/4] net: Introduce generic failover module

On Wed, May 02, 2018 at 10:51:12AM -0700, Samudrala, Sridhar wrote: > > > On 5/2/2018 9:15 AM, Jiri Pirko wrote: > > Sat, Apr 28, 2018 at 11:06:01AM CEST, jiri at resnulli.us wrote: > > > Fri, Apr 27, 2018 at 07:06:58PM CEST, sridhar.samudrala at intel.com wrote: > > [...] > > > > > > > > + > > > > + err =

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

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

On 5/2/2018 9:15 AM, Jiri Pirko wrote: > Sat, Apr 28, 2018 at 11:06:01AM CEST, jiri at resnulli.us wrote: >> Fri, Apr 27, 2018 at 07:06:58PM CEST, sridhar.samudrala at intel.com wrote: > [...] > > >>> + >>> + err = netdev_rx_handler_register(slave_dev, net_failover_handle_frame, >>> + failover_dev); >>> + if (err) { >>> +

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 net_failover driver provides an automated failover mechanism via APIs to create and destroy a failover master netdev and mananges a primary and standby slave netdevs that get registered via the generic failover infrastructure. The failover netdev acts a master device and controls 2 slave devices. The original paravirtual interface gets registered as 'standby' slave netdev and a

This provides a generic interface for paravirtual drivers to listen for netdev register/unregister/link change events from pci ethernet devices with the same MAC and takeover their datapath. The notifier and event handling code is based on the existing netvsc implementation. It exposes 2 sets of interfaces to the paravirtual drivers. 1. For paravirtual drivers like virtio_net that use 3 netdev

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

On Thu, Apr 19, 2018 at 06:42:02PM -0700, Sridhar Samudrala wrote: > This provides a generic interface for paravirtual drivers to listen > for netdev register/unregister/link change events from pci ethernet > devices with the same MAC and takeover their datapath. The notifier and > event handling code is based on the existing netvsc implementation. > > It exposes 2 sets of

On Thu, Apr 19, 2018 at 06:42:02PM -0700, Sridhar Samudrala wrote: > This provides a generic interface for paravirtual drivers to listen > for netdev register/unregister/link change events from pci ethernet > devices with the same MAC and takeover their datapath. The notifier and > event handling code is based on the existing netvsc implementation. > > It exposes 2 sets of

On Mon, 7 May 2018 15:10:44 -0700 Sridhar Samudrala <sridhar.samudrala at intel.com> wrote: > + if (netif_running(failover_dev)) { > + err = dev_open(slave_dev); > + if (err && (err != -EBUSY)) { > + netdev_err(failover_dev, "Opening slave %s failed err:%d\n", > + slave_dev->name, err); > + goto err_dev_open; > + } > + } > + >

On Mon, 7 May 2018 15:10:44 -0700 Sridhar Samudrala <sridhar.samudrala at intel.com> wrote: > +static struct net_device *net_failover_get_bymac(u8 *mac, > + struct net_failover_ops **ops) > +{ > + struct net_device *failover_dev; > + struct net_failover *failover; > + > + spin_lock(&net_failover_lock); > + list_for_each_entry(failover,

On Mon, 7 May 2018 15:10:44 -0700 Sridhar Samudrala <sridhar.samudrala at intel.com> wrote: > +static struct net_device *net_failover_get_bymac(u8 *mac, > + struct net_failover_ops **ops) > +{ > + struct net_device *failover_dev; > + struct net_failover *failover; > + > + spin_lock(&net_failover_lock); > + list_for_each_entry(failover,

On Wed, Mar 06, 2019 at 10:08:32PM -0500, Si-Wei Liu wrote: > When a netdev appears through hot plug then gets enslaved by a failover > master that is already up and running, the slave will be opened > right away after getting enslaved. Today there's a race that userspace > (udev) may fail to rename the slave if the kernel (net_failover) > opens the slave earlier than when the

On Wed, Mar 06, 2019 at 10:08:32PM -0500, Si-Wei Liu wrote: > When a netdev appears through hot plug then gets enslaved by a failover > master that is already up and running, the slave will be opened > right away after getting enslaved. Today there's a race that userspace > (udev) may fail to rename the slave if the kernel (net_failover) > opens the slave earlier than when the

On Fri, Apr 20, 2018 at 08:21:00AM -0700, Samudrala, Sridhar wrote: > > > + finfo = netdev_priv(failover_dev); > > > + > > > + primary_dev = rtnl_dereference(finfo->primary_dev); > > > + standby_dev = rtnl_dereference(finfo->standby_dev); > > > + > > > + if (slave_dev != primary_dev && slave_dev != standby_dev) > > > +

On Thu, 24 May 2018 09:55:13 -0700 Sridhar Samudrala <sridhar.samudrala at intel.com> wrote: > + spin_lock(&failover_lock); Since register is not in fast path, this should be a mutex? > +int failover_slave_unregister(struct net_device *slave_dev) > +{ > + struct net_device *failover_dev; > + struct failover_ops *fops; > + > + if

The failover module provides a generic interface for paravirtual drivers to register a netdev and a set of ops with a failover instance. The ops are used as event handlers that get called to handle netdev register/ unregister/link change/name change events on slave pci ethernet devices with the same mac address as the failover netdev. This enables paravirtual drivers to use a VF as an accelerated

Tim, I reported a protocol data stream error on 9/8/2002 Deatils are in my postes at that time rsync still fails everytime I run it. This time I added three v's as you just suggested and rsync just hung with two tasks in execution thus: root 3178 0.1 0.9 1796 868 pts/1 S 09:57 0:00 /usr/bin/rsync -vvva --delete --exclude=root/snapsh root 3179 0.0 0.6 1628 632 pts/1