> On 21 Mar 2019, at 14:37, Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > On Thu, Mar 21, 2019 at 12:07:57PM +0200, Liran Alon wrote: >>>>>> 2) It brings non-intuitive customer experience. For example, a customer may attempt to analyse connectivity issue by checking the connectivity >>>>>> on a net-failover slave (e.g. the VF) but will see no connectivity when in-fact checking the connectivity on the net-failover master netdev shows correct connectivity. >>>>>> >>>>>> The set of changes I vision to fix our issues are: >>>>>> 1) Hide net-failover slaves in a different netns created and managed by the kernel. But that user can enter to it and manage the netdevs there if wishes to do so explicitly. >>>>>> (E.g. Configure the net-failover VF slave in some special way). >>>>>> 2) Match the virtio-net and the VF based on a PV attribute instead of MAC. (Similar to as done in NetVSC). E.g. Provide a virtio-net interface to get PCI slot where the matching VF will be hot-plugged by hypervisor. >>>>>> 3) Have an explicit virtio-net control message to command hypervisor to switch data-path from virtio-net to VF and vice-versa. Instead of relying on intercepting the PCI master enable-bit >>>>>> as an indicator on when VF is about to be set up. (Similar to as done in NetVSC). >>>>>> >>>>>> Is there any clear issue we see regarding the above suggestion? >>>>>> >>>>>> -Liran >>>>> >>>>> The issue would be this: how do we avoid conflicting with namespaces >>>>> created by users? >>>> >>>> This is kinda controversial, but maybe separate netns names into 2 groups: hidden and normal. >>>> To reference a hidden netns, you need to do it explicitly. >>>> Hidden and normal netns names can collide as they will be maintained in different namespaces (Yes I’m overloading the term namespace here…). >>> >>> Maybe it's an unnamed namespace. Hidden until userspace gives it a name? >> >> This is also a good idea that will solve the issue. Yes. >> >>> >>>> Does this seems reasonable? >>>> >>>> -Liran >>> >>> Reasonable I'd say yes, easy to implement probably no. But maybe I >>> missed a trick or two. >> >> BTW, from a practical point of view, I think that even until we figure out a solution on how to implement this, >> it was better to create an kernel auto-generated name (e.g. “kernel_net_failover_slaves") >> that will break only userspace workloads that by a very rare-chance have a netns that collides with this then >> the breakage we have today for the various userspace components. >> >> -Liran > > It seems quite easy to supply that as a module parameter. Do we need two > namespaces though? Won't some userspace still be confused by the two > slaves sharing the MAC address? That’s one reasonable option. Another one is that we will indeed change the mechanism by which we determine a VF should be bonded with a virtio-net device. i.e. Expose a new virtio-net property that specify the PCI slot of the VF to be bonded with. The second seems cleaner but I don’t have a strong opinion on this. Both seem reasonable to me and your suggestion is faster to implement from current state of things. -Liran > > -- > MST _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
