search for: phys_port_name

...VM image that was using virtio. As such we were trying to make it so that the bypass interface takes the place of the original virtio and get udev to rename the bypass to what the original virtio_net was. > FWIW two solutions that immediately come to mind is to export "backup" > as phys_port_name of the backup virtio link and/or assign a name to the > master like you are doing already. I think team uses team%d and bond > uses bond%d, soft naming of master devices seems quite natural in this > case. I figured I had overlooked something like that.. Thanks for pointing this out. Oka...

...VM image that was using virtio. As such we were trying to make it so that the bypass interface takes the place of the original virtio and get udev to rename the bypass to what the original virtio_net was. > FWIW two solutions that immediately come to mind is to export "backup" > as phys_port_name of the backup virtio link and/or assign a name to the > master like you are doing already. I think team uses team%d and bond > uses bond%d, soft naming of master devices seems quite natural in this > case. I figured I had overlooked something like that.. Thanks for pointing this out. Oka...

...ld have a PCI/PCIe tree topology that makes this easier to sort out, and the "virtio-bond would be used to handle coordination/configuration of a much more complex interface. >> >>> FWIW two solutions that immediately come to mind is to export "backup" >>> as phys_port_name of the backup virtio link and/or assign a name to the >>> master like you are doing already. I think team uses team%d and bond >>> uses bond%d, soft naming of master devices seems quite natural in this >>> case. >> >> I figured I had overlooked something like...

...ld have a PCI/PCIe tree topology that makes this easier to sort out, and the "virtio-bond would be used to handle coordination/configuration of a much more complex interface. >> >>> FWIW two solutions that immediately come to mind is to export "backup" >>> as phys_port_name of the backup virtio link and/or assign a name to the >>> master like you are doing already. I think team uses team%d and bond >>> uses bond%d, soft naming of master devices seems quite natural in this >>> case. >> >> I figured I had overlooked something like...

...f a PITA in the switchdev eswitch mode world, with libvirt expecting only certain devices to be there.. Right now we're not linking VF reprs, which breaks naming. I wanted to revisit that. > > FWIW two solutions that immediately come to mind is to export "backup" > > as phys_port_name of the backup virtio link and/or assign a name to the > > master like you are doing already. I think team uses team%d and bond > > uses bond%d, soft naming of master devices seems quite natural in this > > case. > > I figured I had overlooked something like that.. Thanks...

(pruned to reduce thread) On Wed, 21 Feb 2018 16:17:19 -0800 Alexander Duyck <alexander.duyck at gmail.com> wrote: > >>> FWIW two solutions that immediately come to mind is to export "backup" > >>> as phys_port_name of the backup virtio link and/or assign a name to the > >>> master like you are doing already. I think team uses team%d and bond > >>> uses bond%d, soft naming of master devices seems quite natural in this > >>> case. > >> > >> I figured I ha...

...a different function slot afterwards. Perhaps we might need to a special multiseat like QEMU device for that purpose? Our case we'll upgrade the config from VF to virtio-bypass directly. > >> FWIW two solutions that immediately come to mind is to export "backup" >> as phys_port_name of the backup virtio link and/or assign a name to the >> master like you are doing already. I think team uses team%d and bond >> uses bond%d, soft naming of master devices seems quite natural in this >> case. > > I figured I had overlooked something like that.. Thanks for p...

...ordination/configuration of a much more >> complex interface. > That was one way to solve this problem but I'd like to see simple ways > to sort it out. > >>>>> FWIW two solutions that immediately come to mind is to export "backup" >>>>> as phys_port_name of the backup virtio link and/or assign a name to the >>>>> master like you are doing already. I think team uses team%d and bond >>>>> uses bond%d, soft naming of master devices seems quite natural in this >>>>> case. >>>> I figured I had ov...

...ordination/configuration of a much more >> complex interface. > That was one way to solve this problem but I'd like to see simple ways > to sort it out. > >>>>> FWIW two solutions that immediately come to mind is to export "backup" >>>>> as phys_port_name of the backup virtio link and/or assign a name to the >>>>> master like you are doing already. I think team uses team%d and bond >>>>> uses bond%d, soft naming of master devices seems quite natural in this >>>>> case. >>>> I figured I had ov...

...; to be renamed is the 'bypass' netdev, but the order in which udev gets > to rename the 2 netdevs is not reliable. Out of curiosity - why do you link the master netdev to the virtio struct device? FWIW two solutions that immediately come to mind is to export "backup" as phys_port_name of the backup virtio link and/or assign a name to the master like you are doing already. I think team uses team%d and bond uses bond%d, soft naming of master devices seems quite natural in this case. IMHO phys_port_name == "backup" if BACKUP bit is set on slave virtio link is quite neat...

...ndle coordination/configuration of a much more > complex interface. That was one way to solve this problem but I'd like to see simple ways to sort it out. > >>> >>>> FWIW two solutions that immediately come to mind is to export "backup" >>>> as phys_port_name of the backup virtio link and/or assign a name to the >>>> master like you are doing already. I think team uses team%d and bond >>>> uses bond%d, soft naming of master devices seems quite natural in this >>>> case. >>> >>> I figured I had overl...

...h more >>> complex interface. >> >> That was one way to solve this problem but I'd like to see simple ways >> to sort it out. >> >>>>>> FWIW two solutions that immediately come to mind is to export "backup" >>>>>> as phys_port_name of the backup virtio link and/or assign a name to >>>>>> the >>>>>> master like you are doing already. I think team uses team%d and bond >>>>>> uses bond%d, soft naming of master devices seems quite natural in this >>>>>> case...

Patch 1 introduces a new feature bit VIRTIO_NET_F_BACKUP that can be used by hypervisor to indicate that virtio_net interface should act as a backup for another device with the same MAC address. 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

Patch 1 introduces a new feature bit VIRTIO_NET_F_BACKUP that can be used by hypervisor to indicate that virtio_net interface should act as a backup for another device with the same MAC address. 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

...erspace daemon to setup or tear down. Ideally with this solution the virtio bypass will come up and be assigned the name of the original virtio, and the "backup" interface will come up and be assigned the name of the original virtio with an additional "nbackup" tacked on via the phys_port_name, and then whenever a VF is added it will automatically be enslaved by the bypass interface, and it will be removed when the VF is hotplugged out. In my mind the difference between this and bond or team is where the configuration interface lies. In the case of bond it is in the kernel. If my unders...

...erspace daemon to setup or tear down. Ideally with this solution the virtio bypass will come up and be assigned the name of the original virtio, and the "backup" interface will come up and be assigned the name of the original virtio with an additional "nbackup" tacked on via the phys_port_name, and then whenever a VF is added it will automatically be enslaved by the bypass interface, and it will be removed when the VF is hotplugged out. In my mind the difference between this and bond or team is where the configuration interface lies. In the case of bond it is in the kernel. If my unders...

...o setup or >tear down. Ideally with this solution the virtio bypass will come up >and be assigned the name of the original virtio, and the "backup" >interface will come up and be assigned the name of the original virtio >with an additional "nbackup" tacked on via the phys_port_name, and >then whenever a VF is added it will automatically be enslaved by the >bypass interface, and it will be removed when the VF is hotplugged >out. > >In my mind the difference between this and bond or team is where the >configuration interface lies. In the case of bond it is in...

...gt;tear down. Ideally with this solution the virtio bypass will come up >>and be assigned the name of the original virtio, and the "backup" >>interface will come up and be assigned the name of the original virtio >>with an additional "nbackup" tacked on via the phys_port_name, and >>then whenever a VF is added it will automatically be enslaved by the >>bypass interface, and it will be removed when the VF is hotplugged >>out. >> >>In my mind the difference between this and bond or team is where the >>configuration interface lies. In th...

...ou are trying to achieve by this? > >> >> >> > device is not an upper dev. >> > Can you point to your port flavours patchset? Is it upstream? >> I sent rfc couple of weeks ago: >> [patch net-next RFC 00/12] devlink: introduce port flavours and common phys_port_name generation > > >

...ou are trying to achieve by this? > >> >> >> > device is not an upper dev. >> > Can you point to your port flavours patchset? Is it upstream? >> I sent rfc couple of weeks ago: >> [patch net-next RFC 00/12] devlink: introduce port flavours and common phys_port_name generation > > >