search for: representor

...;>>The signaling isn't too much of an issue since we can just tweak the >>>link state of the VF or virtio manually to report the link up or down >>>prior to the hot-plug. Now that we are on the same page with the team0 > >> Oh, so you just do "ip link set vfrepresentor down" in the host. >> That makes sense. I'm pretty sure that this is not implemented for all >> drivers now. > >mlx5 supports that, on the representor close ndo we take the VF link >operational v-link down > >We should probably also put into the picture some/more...

...nd out there. Also I haven't seen us address what happens as far as how we will handle this on the host. My thought was we should have a paired interface. Something like veth, but made up of a bond on each end. So in the host we should have one bond that has a tap/vhost interface and a VF port representor, and on the other we would be looking at the virtio interface and the VF. Attaching the tap/vhost to the bond could be a way of triggering the feature bit to be set in the virtio. That way communication between the guest and the host won't get too confusing as you will see all traffic from the...

On 1/3/2018 8:59 AM, Alexander Duyck wrote: > On Tue, Jan 2, 2018 at 6:16 PM, Jakub Kicinski <kubakici at wp.pl> wrote: >> On Tue, 2 Jan 2018 16:35:36 -0800, Sridhar Samudrala wrote: >>> This patch series enables virtio to switch over to a VF datapath when a VF >>> netdev is present with the same MAC address. It allows live migration of a VM >>> with a

On Tue, Jan 2, 2018 at 6:16 PM, Jakub Kicinski <kubakici at wp.pl> wrote: > On Tue, 2 Jan 2018 16:35:36 -0800, Sridhar Samudrala wrote: >> This patch series enables virtio to switch over to a VF datapath when a VF >> netdev is present with the same MAC address. It allows live migration of a VM >> with a direct attached VF without the need to setup a bond/team between a

On Tue, Jan 2, 2018 at 6:16 PM, Jakub Kicinski <kubakici at wp.pl> wrote: > On Tue, 2 Jan 2018 16:35:36 -0800, Sridhar Samudrala wrote: >> This patch series enables virtio to switch over to a VF datapath when a VF >> netdev is present with the same MAC address. It allows live migration of a VM >> with a direct attached VF without the need to setup a bond/team between a

...ndle this on the host. My thought was we should have a paired >>>>>>> interface. Something like veth, but made up of a bond on each end. So >>>>>>> in the host we should have one bond that has a tap/vhost interface and >>>>>>> a VF port representor, and on the other we would be looking at the >>>>>>> virtio interface and the VF. Attaching the tap/vhost to the bond could >>>>>>> be a way of triggering the feature bit to be set in the virtio. That >>>>>>> way communication between t...

...to learn. > It's certainly a way to do this, but certainly not the only one. > >> In my mind the VF >> should know who is local and who isn't. > Right. But note that these things change. > >> In the case of SwitchDev it >> should be possible for the port representors and the switch to provide >> data on which interfaces are bonded on the host side and which aren't. >> With that data it would be pretty easy to just put together a list of >> addresses that would prefer to go the para-virtual route instead of >> being transmitted throu...

...to learn. > It's certainly a way to do this, but certainly not the only one. > >> In my mind the VF >> should know who is local and who isn't. > Right. But note that these things change. > >> In the case of SwitchDev it >> should be possible for the port representors and the switch to provide >> data on which interfaces are bonded on the host side and which aren't. >> With that data it would be pretty easy to just put together a list of >> addresses that would prefer to go the para-virtual route instead of >> being transmitted throu...

...g a bridge with a dedicated device for east/west would let > bridge use standard learning techniques for that perhaps? I'm not sure about having the guest have to learn. In my mind the VF should know who is local and who isn't. In the case of SwitchDev it should be possible for the port representors and the switch to provide data on which interfaces are bonded on the host side and which aren't. With that data it would be pretty easy to just put together a list of addresses that would prefer to go the para-virtual route instead of being transmitted through physical hardware. In addition a...

...g a bridge with a dedicated device for east/west would let > bridge use standard learning techniques for that perhaps? I'm not sure about having the guest have to learn. In my mind the VF should know who is local and who isn't. In the case of SwitchDev it should be possible for the port representors and the switch to provide data on which interfaces are bonded on the host side and which aren't. With that data it would be pretty easy to just put together a list of addresses that would prefer to go the para-virtual route instead of being transmitted through physical hardware. In addition a...

...erent then what you suggest. Consider following scenario: - baremetal has 2 sr-iov nics - there is a vm, has 1 VF from each nics: vf0, vf1. No virtio_net - baremetal would like to somehow tell the VM to bond vf0 and vf1 together and how this bonding should be configured, according to how the VF representors are configured on the baremetal (LACP for example) The baremetal could decide to remove any VF during the VM runtime, it can add another VF there. For migration, it can add virtio_net. The VM should be inctructed to bond all interfaces together according to how baremetal decided - as it knows bet...

...All the arguments seem to either saying that semantically this doesn't look like a bond OR suggesting usecases that this patch is not trying to solve. This approach should help cloud environments where the guest networking is fully controlled from the hypervisor via the PF driver or via port representor when switchdev mode is enabled. The guest admin is not expected or allowed to make any networking changes from the VM. > >> With 2 netdev model, any VM image that has a working network >> configuration will transparently get VF based acceleration without >> any changes. >...

On Wed, Feb 21, 2018 at 11:38 AM, Jiri Pirko <jiri at resnulli.us> wrote: > Wed, Feb 21, 2018 at 06:56:35PM CET, alexander.duyck at gmail.com wrote: >>On Wed, Feb 21, 2018 at 8:58 AM, Jiri Pirko <jiri at resnulli.us> wrote: >>> Wed, Feb 21, 2018 at 05:49:49PM CET, alexander.duyck at gmail.com wrote: >>>>On Wed, Feb 21, 2018 at 8:11 AM, Jiri Pirko <jiri

On Wed, Feb 21, 2018 at 11:38 AM, Jiri Pirko <jiri at resnulli.us> wrote: > Wed, Feb 21, 2018 at 06:56:35PM CET, alexander.duyck at gmail.com wrote: >>On Wed, Feb 21, 2018 at 8:58 AM, Jiri Pirko <jiri at resnulli.us> wrote: >>> Wed, Feb 21, 2018 at 05:49:49PM CET, alexander.duyck at gmail.com wrote: >>>>On Wed, Feb 21, 2018 at 8:11 AM, Jiri Pirko <jiri

...st. Consider following scenario: > - baremetal has 2 sr-iov nics > - there is a vm, has 1 VF from each nics: vf0, vf1. No virtio_net > - baremetal would like to somehow tell the VM to bond vf0 and vf1 > together and how this bonding should be configured, according to how > the VF representors are configured on the baremetal (LACP for example) > > The baremetal could decide to remove any VF during the VM runtime, it > can add another VF there. For migration, it can add virtio_net. The VM > should be inctructed to bond all interfaces together according to how > baremetal d...

...st. Consider following scenario: > - baremetal has 2 sr-iov nics > - there is a vm, has 1 VF from each nics: vf0, vf1. No virtio_net > - baremetal would like to somehow tell the VM to bond vf0 and vf1 > together and how this bonding should be configured, according to how > the VF representors are configured on the baremetal (LACP for example) > > The baremetal could decide to remove any VF during the VM runtime, it > can add another VF there. For migration, it can add virtio_net. The VM > should be inctructed to bond all interfaces together according to how > baremetal d...

...to do this, but certainly not the only one. > > > >> In my mind the VF > >> should know who is local and who isn't. > > Right. But note that these things change. > > > >> In the case of SwitchDev it > >> should be possible for the port representors and the switch to provide > >> data on which interfaces are bonded on the host side and which aren't. > >> With that data it would be pretty easy to just put together a list of > >> addresses that would prefer to go the para-virtual route instead of > >> bei...

...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 logic in the path. We can do that later when we start looking at v2 which would likely have us spawn a new device that acts as some sort of smart PCI bridge/PCIe switch th...

...sure about having the guest have to learn. It's certainly a way to do this, but certainly not the only one. > In my mind the VF > should know who is local and who isn't. Right. But note that these things change. > In the case of SwitchDev it > should be possible for the port representors and the switch to provide > data on which interfaces are bonded on the host side and which aren't. > With that data it would be pretty easy to just put together a list of > addresses that would prefer to go the para-virtual route instead of > being transmitted through physical hard...

...https://lists.linuxfoundation.org/mailman/listinfo/virtualization > > I do not see why to couple the solution with any specific para-virt technology. Not with netvsc, nor with virt-io. One may wish to implement the routing between the VMs and the HV without any PV device at all, e.g using VF representors and PCIe loopback, as done with ASAP2-direct. This method is actually much more efficient in CPU utilization (on the expense of PCIe BW utilization). So let's try to first specify the problems that need to be resolved in order to support Live Migration with SR-IOV rather than rely on already-...