search for: ens1nbackup

...figured I had overlooked something like that.. Thanks for pointing this out. Okay so I think the phys_port_name approach might resolve the original issue. If I am reading things correctly what we end up with is the master showing up as "ens1" for example and the backup showing up as "ens1nbackup". Am I understanding that right? The problem with the team/bond%d approach is that it creates a new netdevice and so it would require guest configuration changes. > IMHO phys_port_name == "backup" if BACKUP bit is set on slave virtio > link is quite neat. I agree. For non-&q...

...figured I had overlooked something like that.. Thanks for pointing this out. Okay so I think the phys_port_name approach might resolve the original issue. If I am reading things correctly what we end up with is the master showing up as "ens1" for example and the backup showing up as "ens1nbackup". Am I understanding that right? The problem with the team/bond%d approach is that it creates a new netdevice and so it would require guest configuration changes. > IMHO phys_port_name == "backup" if BACKUP bit is set on slave virtio > link is quite neat. I agree. For non-&q...

...ike that.. Thanks for pointing >> this out. Okay so I think the phys_port_name approach might resolve >> the original issue. If I am reading things correctly what we end up >> with is the master showing up as "ens1" for example and the backup >> showing up as "ens1nbackup". Am I understanding that right? >> >> The problem with the team/bond%d approach is that it creates a new >> netdevice and so it would require guest configuration changes. >> >>> IMHO phys_port_name == "backup" if BACKUP bit is set on slave virtio &gt...

...ike that.. Thanks for pointing >> this out. Okay so I think the phys_port_name approach might resolve >> the original issue. If I am reading things correctly what we end up >> with is the master showing up as "ens1" for example and the backup >> showing up as "ens1nbackup". Am I understanding that right? >> >> The problem with the team/bond%d approach is that it creates a new >> netdevice and so it would require guest configuration changes. >> >>> IMHO phys_port_name == "backup" if BACKUP bit is set on slave virtio &gt...

...f you can't tell) that it is okay to rip out in-driver XDP from virtio_net, then you could transition between base virtio, virtio w/ backup bit set. - Works for netvsc because they limit their features (no in-driver XDP) to guarantee this works. 3 Netdev model, "ens1", enslaves "ens1nbackup" and "ens2" - Exposes 2 netdevs "ens1" and "ens1nbackup" when only virtio is present - No extra qdisc or locking - All virtio_net original functionality still present - Not able to transition from virtio to virtio w/ backup without disruption (requires hot-plug)...

...f you can't tell) that it is okay to rip out in-driver XDP from virtio_net, then you could transition between base virtio, virtio w/ backup bit set. - Works for netvsc because they limit their features (no in-driver XDP) to guarantee this works. 3 Netdev model, "ens1", enslaves "ens1nbackup" and "ens2" - Exposes 2 netdevs "ens1" and "ens1nbackup" when only virtio is present - No extra qdisc or locking - All virtio_net original functionality still present - Not able to transition from virtio to virtio w/ backup without disruption (requires hot-plug)...

...oked something like that.. Thanks for pointing > this out. Okay so I think the phys_port_name approach might resolve > the original issue. If I am reading things correctly what we end up > with is the master showing up as "ens1" for example and the backup > showing up as "ens1nbackup". Am I understanding that right? Yes, provided systemd is new enough. > The problem with the team/bond%d approach is that it creates a new > netdevice and so it would require guest configuration changes. > > > IMHO phys_port_name == "backup" if BACKUP bit is set on s...

...) that it is okay to rip out in-driver XDP from virtio_net, then >you could transition between base virtio, virtio w/ backup bit set. >- Works for netvsc because they limit their features (no in-driver >XDP) to guarantee this works. > >3 Netdev model, "ens1", enslaves "ens1nbackup" and "ens2" >- Exposes 2 netdevs "ens1" and "ens1nbackup" when only virtio is present >- No extra qdisc or locking >- All virtio_net original functionality still present >- Not able to transition from virtio to virtio w/ backup without >disruption (...

...rip out in-driver XDP from virtio_net, then >>you could transition between base virtio, virtio w/ backup bit set. >>- Works for netvsc because they limit their features (no in-driver >>XDP) to guarantee this works. >> >>3 Netdev model, "ens1", enslaves "ens1nbackup" and "ens2" >>- Exposes 2 netdevs "ens1" and "ens1nbackup" when only virtio is present >>- No extra qdisc or locking >>- All virtio_net original functionality still present >>- Not able to transition from virtio to virtio w/ backup without...

...rip out in-driver XDP from virtio_net, then >>you could transition between base virtio, virtio w/ backup bit set. >>- Works for netvsc because they limit their features (no in-driver >>XDP) to guarantee this works. >> >>3 Netdev model, "ens1", enslaves "ens1nbackup" and "ens2" >>- Exposes 2 netdevs "ens1" and "ens1nbackup" when only virtio is present >>- No extra qdisc or locking >>- All virtio_net original functionality still present >>- Not able to transition from virtio to virtio w/ backup without...

...r pointing > >> this out. Okay so I think the phys_port_name approach might resolve > >> the original issue. If I am reading things correctly what we end up > >> with is the master showing up as "ens1" for example and the backup > >> showing up as "ens1nbackup". Am I understanding that right? > >> > >> The problem with the team/bond%d approach is that it creates a new > >> netdevice and so it would require guest configuration changes. > >> > >>> IMHO phys_port_name == "backup" if BACKUP bit...

...DP from virtio_net, then >>>you could transition between base virtio, virtio w/ backup bit set. >>>- Works for netvsc because they limit their features (no in-driver >>>XDP) to guarantee this works. >>> >>>3 Netdev model, "ens1", enslaves "ens1nbackup" and "ens2" >>>- Exposes 2 netdevs "ens1" and "ens1nbackup" when only virtio is present >>>- No extra qdisc or locking >>>- All virtio_net original functionality still present >>>- Not able to transition from virtio to virtio w/...

...oked something like that.. Thanks for pointing > this out. Okay so I think the phys_port_name approach might resolve > the original issue. If I am reading things correctly what we end up > with is the master showing up as "ens1" for example and the backup > showing up as "ens1nbackup". Am I understanding that right? > > The problem with the team/bond%d approach is that it creates a new > netdevice and so it would require guest configuration changes. > >> IMHO phys_port_name == "backup" if BACKUP bit is set on slave virtio >> link is quite...

...then >>>>you could transition between base virtio, virtio w/ backup bit set. >>>>- Works for netvsc because they limit their features (no in-driver >>>>XDP) to guarantee this works. >>>> >>>>3 Netdev model, "ens1", enslaves "ens1nbackup" and "ens2" >>>>- Exposes 2 netdevs "ens1" and "ens1nbackup" when only virtio is present >>>>- No extra qdisc or locking >>>>- All virtio_net original functionality still present >>>>- Not able to transition from vir...

...then >>>>you could transition between base virtio, virtio w/ backup bit set. >>>>- Works for netvsc because they limit their features (no in-driver >>>>XDP) to guarantee this works. >>>> >>>>3 Netdev model, "ens1", enslaves "ens1nbackup" and "ens2" >>>>- Exposes 2 netdevs "ens1" and "ens1nbackup" when only virtio is present >>>>- No extra qdisc or locking >>>>- All virtio_net original functionality still present >>>>- Not able to transition from vir...

...gt;>>> this out. Okay so I think the phys_port_name approach might resolve >>>> the original issue. If I am reading things correctly what we end up >>>> with is the master showing up as "ens1" for example and the backup >>>> showing up as "ens1nbackup". Am I understanding that right? >>>> >>>> The problem with the team/bond%d approach is that it creates a new >>>> netdevice and so it would require guest configuration changes. >>>> >>>>> IMHO phys_port_name == "backup"...

...gt;>>> this out. Okay so I think the phys_port_name approach might resolve >>>> the original issue. If I am reading things correctly what we end up >>>> with is the master showing up as "ens1" for example and the backup >>>> showing up as "ens1nbackup". Am I understanding that right? >>>> >>>> The problem with the team/bond%d approach is that it creates a new >>>> netdevice and so it would require guest configuration changes. >>>> >>>>> IMHO phys_port_name == "backup"...

On Wed, Feb 21, 2018 at 8:11 AM, Jiri Pirko <jiri at resnulli.us> wrote: > Wed, Feb 21, 2018 at 04:56:48PM CET, alexander.duyck at gmail.com wrote: >>On Wed, Feb 21, 2018 at 1:51 AM, Jiri Pirko <jiri at resnulli.us> wrote: >>> Tue, Feb 20, 2018 at 11:33:56PM CET, kubakici at wp.pl wrote: >>>>On Tue, 20 Feb 2018 21:14:10 +0100, Jiri Pirko wrote:

On Wed, Feb 21, 2018 at 8:11 AM, Jiri Pirko <jiri at resnulli.us> wrote: > Wed, Feb 21, 2018 at 04:56:48PM CET, alexander.duyck at gmail.com wrote: >>On Wed, Feb 21, 2018 at 1:51 AM, Jiri Pirko <jiri at resnulli.us> wrote: >>> Tue, Feb 20, 2018 at 11:33:56PM CET, kubakici at wp.pl wrote: >>>>On Tue, 20 Feb 2018 21:14:10 +0100, Jiri Pirko wrote:

...s for pointing >>> this out. Okay so I think the phys_port_name approach might resolve >>> the original issue. If I am reading things correctly what we end up >>> with is the master showing up as "ens1" for example and the backup >>> showing up as "ens1nbackup". Am I understanding that right? >>> >>> The problem with the team/bond%d approach is that it creates a new >>> netdevice and so it would require guest configuration changes. >>> >>>> IMHO phys_port_name == "backup" if BACKUP bit is set...