search for: switchdev

Displaying 20 results from an estimated 49 matches for "switchdev".

2018 Jun 22
2
[virtio-dev] Re: [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
...pretty orthogonal to host/guest interface. > > Jason said virtio net is sometimes preferable. > > If that's the case don't make it a standby. > > > > More advanced use-cases do exist and e.g. Alexander Duyck > > suggested using a switch-dev. > > The switchdev case would need a new feature bit, right? > > -Siwei I think it would need to be a completely new device. > > failover isn't it though. > > > > -- > > MST
2018 Jan 23
2
[virtio-dev] [RFC PATCH net-next v2 1/2] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit
...even if it's spawned automatically. 6. XDP redirect use-case (or any explicit use of the virtio slave) (from MST) independent driver: 7. code reuse. separate device: 8. bond any netdev with any netdev. 9. reuse well-known device driver model. a. natural anchor for hypervisor configuration (switchdev etc.) b. next-gen silicon may be able to disguise as virtio device, and the loop check in virtio driver will prevent the legitimate bond it such case. AFAIU that's one of the goals of next-gen virtio spec as well.
2018 Jan 23
2
[virtio-dev] [RFC PATCH net-next v2 1/2] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit
...even if it's spawned automatically. 6. XDP redirect use-case (or any explicit use of the virtio slave) (from MST) independent driver: 7. code reuse. separate device: 8. bond any netdev with any netdev. 9. reuse well-known device driver model. a. natural anchor for hypervisor configuration (switchdev etc.) b. next-gen silicon may be able to disguise as virtio device, and the loop check in virtio driver will prevent the legitimate bond it such case. AFAIU that's one of the goals of next-gen virtio spec as well.
2018 Jan 26
2
[virtio-dev] Re: [RFC PATCH net-next v2 2/2] virtio_net: Extend virtio to use VF datapath when available
...39;re unwilling to move towards it, we'd > > take this one and come back with a generic solution that is able to > > address general use cases for VF/PT live migration . > > I think that's a fine approach. Scratch your own itch! I imagine a very > generic virtio-switchdev providing host routing info to guests could > address lots of usecases. A driver could bind to that one and enslave > arbitrary other devices. Sounds reasonable. > > But given the fundamental idea of a failover was floated at least as > early as 2013, and made 0 progress since prec...
2018 Jan 22
5
[virtio-dev] [RFC PATCH net-next v2 1/2] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit
...d and I see this being the mechanism for it to do so. From there >> the complexity mostly lies in the pass-thru interface to configure the >> correct transmit modes if for example you have multiple pass-thru >> interfaces or a more complex traffic setup due to things like >> SwitchDev. >> >> In my mind we go the bonding route and there are few use cases for all >> of this. First is the backup case that is being addressed here. That >> becomes your basic "copy netvsc" approach for this which would be >> default. It is how we would handle ba...
2018 Jan 22
5
[virtio-dev] [RFC PATCH net-next v2 1/2] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit
...d and I see this being the mechanism for it to do so. From there >> the complexity mostly lies in the pass-thru interface to configure the >> correct transmit modes if for example you have multiple pass-thru >> interfaces or a more complex traffic setup due to things like >> SwitchDev. >> >> In my mind we go the bonding route and there are few use cases for all >> of this. First is the backup case that is being addressed here. That >> becomes your basic "copy netvsc" approach for this which would be >> default. It is how we would handle ba...
2018 Jan 17
2
[virtio-dev] [RFC PATCH net-next v2 1/2] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit
...formation to get itself into the bond and I see this being the mechanism for it to do so. From there the complexity mostly lies in the pass-thru interface to configure the correct transmit modes if for example you have multiple pass-thru interfaces or a more complex traffic setup due to things like SwitchDev. In my mind we go the bonding route and there are few use cases for all of this. First is the backup case that is being addressed here. That becomes your basic "copy netvsc" approach for this which would be default. It is how we would handle basic pass-thru back-up paths. If the host dec...
2018 Jan 17
2
[virtio-dev] [RFC PATCH net-next v2 1/2] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit
...formation to get itself into the bond and I see this being the mechanism for it to do so. From there the complexity mostly lies in the pass-thru interface to configure the correct transmit modes if for example you have multiple pass-thru interfaces or a more complex traffic setup due to things like SwitchDev. In my mind we go the bonding route and there are few use cases for all of this. First is the backup case that is being addressed here. That becomes your basic "copy netvsc" approach for this which would be default. It is how we would handle basic pass-thru back-up paths. If the host dec...
2018 Jan 27
4
[virtio-dev] Re: [RFC PATCH net-next v2 2/2] virtio_net: Extend virtio to use VF datapath when available
...rds it, we'd > >>> take this one and come back with a generic solution that is able to > >>> address general use cases for VF/PT live migration . > >> I think that's a fine approach. Scratch your own itch! I imagine a very > >> generic virtio-switchdev providing host routing info to guests could > >> address lots of usecases. A driver could bind to that one and enslave > >> arbitrary other devices. Sounds reasonable. > >> > >> But given the fundamental idea of a failover was floated at least as > >> e...
2018 Jan 27
0
[virtio-dev] Re: [RFC PATCH net-next v2 2/2] virtio_net: Extend virtio to use VF datapath when available
...'d >>>>> take this one and come back with a generic solution that is able to >>>>> address general use cases for VF/PT live migration . >>>> I think that's a fine approach. Scratch your own itch! I imagine a very >>>> generic virtio-switchdev providing host routing info to guests could >>>> address lots of usecases. A driver could bind to that one and enslave >>>> arbitrary other devices. Sounds reasonable. >>>> >>>> But given the fundamental idea of a failover was floated at least as &gt...
2018 Jun 22
2
[virtio-dev] Re: [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
On Thu, Jun 21, 2018 at 06:07:18PM -0700, Siwei Liu wrote: > On Thu, Jun 21, 2018 at 11:14 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > > On Wed, Jun 13, 2018 at 01:40:59PM +0800, Jason Wang wrote: > >> > >> > >> On 2018?06?13? 12:24, Samudrala, Sridhar wrote: > >> > On 6/12/2018 7:38 PM, Jason Wang wrote: > >> > >
2018 Jan 23
0
[virtio-dev] [RFC PATCH net-next v2 1/2] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit
...ng the mechanism for it to do so. From there > >> the complexity mostly lies in the pass-thru interface to configure the > >> correct transmit modes if for example you have multiple pass-thru > >> interfaces or a more complex traffic setup due to things like > >> SwitchDev. > >> > >> In my mind we go the bonding route and there are few use cases for all > >> of this. First is the backup case that is being addressed here. That > >> becomes your basic "copy netvsc" approach for this which would be > >> default. It...
2018 Jan 28
0
[virtio-dev] Re: [RFC PATCH net-next v2 2/2] virtio_net: Extend virtio to use VF datapath when available
...g that the VM > can > use both datapaths and i had broadcasts/multicasts going over virtio > datapath, > but i don' think it is a good idea. It requires the device to disable > broadcast > replication on the VFs. > > Thanks > Sridhar This would work well for the SwitchDev model, but not so well for the legacy model supported by the Intel drivers. With SwitchDev the broadcasts/multicasts are coming in on the upllink port representor anyway is my understanding of how some of the implementations out there are configured. For now though we can't assume the logi...
2018 Jan 22
0
[virtio-dev] [RFC PATCH net-next v2 1/2] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit
...nto the > bond and I see this being the mechanism for it to do so. From there > the complexity mostly lies in the pass-thru interface to configure the > correct transmit modes if for example you have multiple pass-thru > interfaces or a more complex traffic setup due to things like > SwitchDev. > > In my mind we go the bonding route and there are few use cases for all > of this. First is the backup case that is being addressed here. That > becomes your basic "copy netvsc" approach for this which would be > default. It is how we would handle basic pass-thru back-...
2018 Jan 23
2
[virtio-dev] [RFC PATCH net-next v2 1/2] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit
...mean a bus device/struct device, but no strong preference on that one. I'll be happy as long as there is a separate netdev, really :) > > 8. bond any netdev with any netdev. > > 9. reuse well-known device driver model. > > a. natural anchor for hypervisor configuration (switchdev etc.) > > saparate netdev has the same property > > > b. next-gen silicon may be able to disguise as virtio device, and the > > loop check in virtio driver will prevent the legitimate bond it such > > case. AFAIU that's one of the goals of next-gen virtio sp...
2018 Jan 23
2
[virtio-dev] [RFC PATCH net-next v2 1/2] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit
...mean a bus device/struct device, but no strong preference on that one. I'll be happy as long as there is a separate netdev, really :) > > 8. bond any netdev with any netdev. > > 9. reuse well-known device driver model. > > a. natural anchor for hypervisor configuration (switchdev etc.) > > saparate netdev has the same property > > > b. next-gen silicon may be able to disguise as virtio device, and the > > loop check in virtio driver will prevent the legitimate bond it such > > case. AFAIU that's one of the goals of next-gen virtio sp...
2018 Jan 26
2
[virtio-dev] Re: [RFC PATCH net-next v2 2/2] virtio_net: Extend virtio to use VF datapath when available
...ure. If you're unwilling to move towards it, we'd take this one and come back with a generic solution that is able to address general use cases for VF/PT live migration . Regards, -Siwei >>> >>> >>>>> So some people want a fully userspace-configurable switchdev, and that >>>>> already exists at some level, and maybe it makes sense to add more >>>>> features for performance. >>>>> >>>>> But the point was that some host configurations are very simple, >>>>> and it probably makes sens...
2018 Jan 22
0
[RFC PATCH net-next v2 2/2] virtio_net: Extend virtio to use VF datapath when available
...ou are saying a separate driver. Further, the reason to have a separate *driver* was that some people wanted to share code with netvsc - and that one does not create a separate device, which you can't change without breaking existing configs. So some people want a fully userspace-configurable switchdev, and that already exists at some level, and maybe it makes sense to add more features for performance. But the point was that some host configurations are very simple, and it probably makes sense to pass this information to the guest and have guest act on it directly. Let's not conflate the tw...
2018 Jan 26
0
[virtio-dev] Re: [RFC PATCH net-next v2 2/2] virtio_net: Extend virtio to use VF datapath when available
...I'm not sure. If you're unwilling to move towards it, we'd > take this one and come back with a generic solution that is able to > address general use cases for VF/PT live migration . I think that's a fine approach. Scratch your own itch! I imagine a very generic virtio-switchdev providing host routing info to guests could address lots of usecases. A driver could bind to that one and enslave arbitrary other devices. Sounds reasonable. But given the fundamental idea of a failover was floated at least as early as 2013, and made 0 progress since precisely because it kept try...
2018 Feb 19
0
[RFC PATCH v3 0/3] Enable virtio_net to act as a backup for a passthru device
...bypass to what the original > virtio_net was. That makes sense. Is it udev/naming that you're most concerned about here? I.e. what's the user space app that expects the netdev to be linked? This is just out of curiosity, the linking of netdevs to devices is a bit of 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 bac...