search for: failover_register

...AILOVER) > + > +int failover_create(struct net_device *standby_dev, > + struct failover **pfailover); Should we rename all these structs net_failover? It's possible to extend the concept to storage I think. > +void failover_destroy(struct failover *failover); > + > +int failover_register(struct net_device *standby_dev, struct failover_ops *ops, > + struct failover **pfailover); > +void failover_unregister(struct failover *failover); > + > +int failover_slave_unregister(struct net_device *slave_dev); > + > +#else > + > +static inline > +int failover...

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

...es to the paravirtual drivers. > 1. existing netvsc driver that uses 2 netdev model. In this model, no > master netdev is created. The paravirtual driver registers each instance > of netvsc as a 'failover' instance along with a set of ops to manage the > slave events. > failover_register() > failover_unregister() > 2. new virtio_net based solution that uses 3 netdev model. In this model, > the failover module provides interfaces to create/destroy additional master > netdev and all the slave events are managed internally. > failover_create() > fail...

...es to the paravirtual drivers. > 1. existing netvsc driver that uses 2 netdev model. In this model, no > master netdev is created. The paravirtual driver registers each instance > of netvsc as a 'failover' instance along with a set of ops to manage the > slave events. > failover_register() > failover_unregister() > 2. new virtio_net based solution that uses 3 netdev model. In this model, > the failover module provides interfaces to create/destroy additional master > netdev and all the slave events are managed internally. > failover_create() > fail...

...xposes 2 sets of interfaces to the paravirtual drivers. 1. existing netvsc driver that uses 2 netdev model. In this model, no master netdev is created. The paravirtual driver registers each instance of netvsc as a 'failover' instance along with a set of ops to manage the slave events. failover_register() failover_unregister() 2. new virtio_net based solution that uses 3 netdev model. In this model, the failover module provides interfaces to create/destroy additional master netdev and all the slave events are managed internally. failover_create() failover_destroy() These functions...

...s the Mellanox >> VF device. >> >> So it depends on existing 2 device model. You can't go to a 3 device model >> or start hiding devices from userspace. > > Okay so how does the existing patch break that? IIUC does not go to > a 3 device model since netvsc calls failover_register directly. > >> Also, I am working on associating netvsc and VF device based on serial number >> rather than MAC address. The serial number is how Windows works now, and it makes >> sense for Linux and Windows to use the same mechanism if possible. > > Maybe we should supp...

...s the Mellanox >> VF device. >> >> So it depends on existing 2 device model. You can't go to a 3 device model >> or start hiding devices from userspace. > > Okay so how does the existing patch break that? IIUC does not go to > a 3 device model since netvsc calls failover_register directly. > >> Also, I am working on associating netvsc and VF device based on serial number >> rather than MAC address. The serial number is how Windows works now, and it makes >> sense for Linux and Windows to use the same mechanism if possible. > > Maybe we should supp...

...ll load its driver and it's too late >> when failover driver is loaded. > > Well, even if we can delay the visibility of primary until DRIVER_OK, > there still be a race I think? And it looks to me it's still a bug of > guest: > > E.g primary could be probed before failover_register() in guest. Then > we will miss the enslaving of primary forever. That is not an issue. Even if the primary is probed before failover driver, it will enslave the primary via the call to failover_existing_slave_register() as part of failover_register() routine. > > Thanks > >> &...

...ll load its driver and it's too late >> when failover driver is loaded. > > Well, even if we can delay the visibility of primary until DRIVER_OK, > there still be a race I think? And it looks to me it's still a bug of > guest: > > E.g primary could be probed before failover_register() in guest. Then > we will miss the enslaving of primary forever. That is not an issue. Even if the primary is probed before failover driver, it will enslave the primary via the call to failover_existing_slave_register() as part of failover_register() routine. > > Thanks > >> &...

...drivers. >> 1. existing netvsc driver that uses 2 netdev model. In this model, no >> master netdev is created. The paravirtual driver registers each instance >> of netvsc as a 'failover' instance along with a set of ops to manage the >> slave events. >> failover_register() >> failover_unregister() >> 2. new virtio_net based solution that uses 3 netdev model. In this model, >> the failover module provides interfaces to create/destroy additional master >> netdev and all the slave events are managed internally. >> failover_cr...

...name_change)(struct net_device *slave_dev, + struct net_device *failover_dev); + rx_handler_result_t (*slave_handle_frame)(struct sk_buff **pskb); +}; + +struct failover { + struct list_head list; + struct net_device __rcu *failover_dev; + struct failover_ops __rcu *ops; +}; + +struct failover *failover_register(struct net_device *dev, + struct failover_ops *ops); +void failover_unregister(struct failover *failover); +int failover_slave_unregister(struct net_device *slave_dev); + +#endif /* _FAILOVER_H */ diff --git a/net/Kconfig b/net/Kconfig index df8d45ef47d8..d581c4f0f1c4 100644 --- a/net/Kconfig...

...ver driver is loaded. > > > > > > Well, even if we can delay the visibility of primary until > > > DRIVER_OK, there still be a race I think? And it looks to me it's > > > still a bug of guest: > > > > > > E.g primary could be probed before failover_register() in guest. > > > Then we will miss the enslaving of primary forever. > > > > That is not an issue. Even if the primary is probed before failover > > driver, it will > > enslave the primary via the call to failover_existing_slave_register() > > as part of &gt...

...; >> So it depends on existing 2 device model. You can't go to a 3 device model > > >> or start hiding devices from userspace. > > > > > > Okay so how does the existing patch break that? IIUC does not go to > > > a 3 device model since netvsc calls failover_register directly. > > > > > >> Also, I am working on associating netvsc and VF device based on serial number > > >> rather than MAC address. The serial number is how Windows works now, and it makes > > >> sense for Linux and Windows to use the same mechanism i...

...9;s too late >>> when failover driver is loaded. >> >> Well, even if we can delay the visibility of primary until DRIVER_OK, >> there still be a race I think? And it looks to me it's still a bug of >> guest: >> >> E.g primary could be probed before failover_register() in guest. Then >> we will miss the enslaving of primary forever. > > That is not an issue. Even if the primary is probed before failover > driver, it will > enslave the primary via the call to failover_existing_slave_register() > as part of > failover_register() routine...

On Mon, 23 Apr 2018 20:24:56 +0300 "Michael S. Tsirkin" <mst at redhat.com> wrote: > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote: > > > > > > > >I will NAK patches to change to common code for netvsc especially the > > > >three device model. MS worked hard with distro vendors to support transparent > > >

On Mon, 23 Apr 2018 20:24:56 +0300 "Michael S. Tsirkin" <mst at redhat.com> wrote: > On Mon, Apr 23, 2018 at 10:04:06AM -0700, Stephen Hemminger wrote: > > > > > > > >I will NAK patches to change to common code for netvsc especially the > > > >three device model. MS worked hard with distro vendors to support transparent > > >

...>> > > >> > > Well, even if we can delay the visibility of primary until >> > > DRIVER_OK, there still be a race I think? And it looks to me it's >> > > still a bug of guest: >> > > >> > > E.g primary could be probed before failover_register() in guest. >> > > Then we will miss the enslaving of primary forever. >> > >> > That is not an issue. Even if the primary is probed before failover >> > driver, it will >> > enslave the primary via the call to failover_existing_slave_register() >&...

...gt;> >> So it depends on existing 2 device model. You can't go to a 3 device model >> >> or start hiding devices from userspace. >> > >> > Okay so how does the existing patch break that? IIUC does not go to >> > a 3 device model since netvsc calls failover_register directly. >> > >> >> Also, I am working on associating netvsc and VF device based on serial number >> >> rather than MAC address. The serial number is how Windows works now, and it makes >> >> sense for Linux and Windows to use the same mechanism if poss...

...gt;> >> So it depends on existing 2 device model. You can't go to a 3 device model >> >> or start hiding devices from userspace. >> > >> > Okay so how does the existing patch break that? IIUC does not go to >> > a 3 device model since netvsc calls failover_register directly. >> > >> >> Also, I am working on associating netvsc and VF device based on serial number >> >> rather than MAC address. The serial number is how Windows works now, and it makes >> >> sense for Linux and Windows to use the same mechanism if poss...

...Linux netvsc device as well as the Mellanox > VF device. > > So it depends on existing 2 device model. You can't go to a 3 device model > or start hiding devices from userspace. Okay so how does the existing patch break that? IIUC does not go to a 3 device model since netvsc calls failover_register directly. > Also, I am working on associating netvsc and VF device based on serial number > rather than MAC address. The serial number is how Windows works now, and it makes > sense for Linux and Windows to use the same mechanism if possible. Maybe we should support same for virtio ... W...