[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] [PATCH v4] content: Introduce VIRTIO_NET_F_STANDBY feature
On Sat, Dec 8, 2018 at 3:54 AM si-wei liu <si-wei.liu@oracle.com> wrote: > > > > On 12/05/2018 08:18 AM, Sameeh Jubran wrote: > > Hi all, > > > > This is a followup on the discussion in the DPDK and Virtio monthly meeting. > > > > Michael suggested that layer 2 tests should be created in order to > > test the PF/VF behavior in different scenarios without using VMs at > > all which should speed up the testing process. > > > > The following "mausezahn" tool - which is part of netsniff-ng package > > - can be used in order to generate layer 2 packets as follows: > > > > mausezahn enp59s0 -c 0 -a rand -b 20:71:c6:2a:68:38 "08 00 aa bb cc dd" > > > > The packets can be sniffed using tcpdump or netsniff-ng. > Does tcpdump or netsniff-ng enable NIC's promiscuous mode by default? > Try disable it when you monitor/capture the L2 packets. netsniff-ng enables promiscuous mode by default, however the -M flag can disable this. > > > > > I am not completely sure how the setup should look like on the host, > > but here is a script which assigns macvlan to the PF and sets it's mac > > address to be the same as the VF mac address. The scripts assumes that > > the sriov is already configured and the vf are present. > > > > [root@wsfd-advnetlab10 ~]# cat go_macvlan.sh > > MACVLAN_NAME=macvlan0 > > PF_NAME=enp59s0 > > VF_NUMBER=1 > > MAC_ADDR=20:71:c6:2a:68:38 > > > > echo "$PF_NAME vf status before setting mac" > > ip link show dev $PF_NAME > > ip link set $PF_NAME vf $VF_NUMBER mac $MAC_ADDR > > ip li add link $PF_NAME $MACVLAN_NAME address $MAC_ADDR type macvlan > > ip link set $PF_NAME up > > echo "$PF_NAME vf status after setting mac" > > ip link show dev $PF_NAME > > > > Please share your thoughts on how the different test scenarios should > > go, I can customize the scripts further more and host them somewhere. > You can do something like below: > > FAKE_VLAN=123 > ip link set $MACVLAN_NAME up > ip link set $PF_NAME vf $VF_NUMBER vlan $FAKE_VLAN > > Datapath now switched to macvlan0, which should get the L2 packets from > over the wire. > > ip link set $PF_NAME vf $VF_NUMBER vlan 0 > ip link set $MACVLAN_NAME down > > Datapath now switched back to VF. VF#1 should get packets. > > For a more accurate downtime test, replace 'ip link set vf .. vlan ...' > to unbind VF from the original driver and bind it to vfio-pci. Yup. > > > Regards, > -Siwei > > > > > On Tue, Dec 4, 2018 at 5:59 AM Michael S. Tsirkin <mst@redhat.com> wrote: > >> On Mon, Dec 03, 2018 at 06:09:19PM -0800, si-wei liu wrote: > >>>> I agree. But a single flag is not much of an extension. We don't even > >>>> need it in netlink, can be anywhere in e.g. sysfs. > >>> I think sysfs attribute is for exposing the capability, while you still need > >>> to set up macvtap with some special mode via netlink. That way it doesn't > >>> break current behavior, and when VF's MAC filter is added macvtap would need > >>> to react to remove the filter from NIC. And add the one back when VF's MAC > >>> is removed. > >> All this will be up to the developers actually working on it. My > >> understanding is that intel is going to just change the behaviour > >> unconditionally, and it's already the case for Mellanox. > >> That creates a critical mass large enough that maybe others > >> just need to confirm. > >> > >> ... > >> > >> > >>>> Meanwhile what's missing and was missing all along for the change you > >>>> seem to be advocating for to get off the ground is people who > >>>> are ready to actually send e.g. spec, guest driver, test patches. > >>> Partly because it hadn't been converged to the best way to do it (even the > >>> group ID mechanism with PCI bridge can address our need you don't seem to > >>> think it is valuable). The in-kernel approach is fine at its appearance, but > >>> I personally don't believe changing every legacy driver is the way to go. > >>> It's the choice of implementation and what has been implemented in those > >>> drivers today IMHO is nothing wrong. > >> It's not a question of being wrong as such. > >> A standard behaviour is clearly better than each driver doing its > >> own thing which is the case now. As long as we ar standardizing, > >> let's standardize on something that matches our needs? > >> But I really see no problem with also supporting other options, > >> as long as someone is prepared to actually put in the work. > >> > >> > >>>>>> Still this assumes just creating a VF > >>>>>> doesn't yet program the on-card filter to cause packet drops. > >>>>> Suppose this behavior is fixable in legacy Intel NIC, you would still need > >>>>> to evacuate the filter programmed by macvtap previously when VF's filter > >>>>> gets activated (typically when VF's netdev is netif_running() in a Linux > >>>>> guest). That's what we and NetVSC call as "datapath switching", and where > >>>>> this could be handled (driver, net core, or userspace) is the core for the > >>>>> architectural design that I spent much time on. > >>>>> > >>>>> Having said it, I don't expect or would desperately wait on one vendor to > >>>>> fix a legacy driver which wasn't quite motivated, then no work would be done > >>>>> on that. > >>>> Then that device can't be used with the mechanism in question. > >>>> Or if there are lots of drivers like this maybe someone will be > >>>> motivated enough to post a better implementation with a new > >>>> feature bit. It's not that I'm arguing against that. > >>>> > >>>> But given the options of teaching management to play with > >>>> netlink API in response to guest actions, and with VCPU stopped, > >>>> and doing it all in host kernel drivers, I know I'll prefer host kernel > >>>> changes. > >>> We have some internal patches that leverage management to respond to various > >>> guest actions. If you're interested we can post them. The thing is no one > >>> would like to work on the libvirt changes, while internally we have our own > >>> orchestration software which is not libvirt. But if you think it's fine we > >>> can definitely share our QEMU patches while leaving out libvirt. > >>> > >>> Thanks, > >>> -Siwei > >> Sure, why not. > >> > >> The following is generally necessary for any virtio project to happen: > >> - guest patches > >> - qemu patches > >> - spec documentation > >> > >> Some extras are sometimes a dependency, e.g. host kernel patches. > >> > >> > >> Typically at least two of these are enough for people to > >> be able to figure out how things work. > >> > >> > >> > >> > >>>>> If you'd go the way, please make sure Intel could change their > >>>>> driver first. > >>>> We'll see what happens with that. It's Sridhar from intel that implemented > >>>> the guest changes after all, so I expect he's motivated to make them > >>>> work well. > >>>> > >>>> > >>>>>> Let's > >>>>>> assume drivers are fixed to do that. How does userspace know > >>>>>> that's the case? We might need some kind of attribute so > >>>>>> userspace can detect it. > >>>>> Where do you envision the new attribute could be at? Supposedly it'd be > >>>>> exposed by the kernel, which constitutes a new API or API changes. > >>>>> > >>>>> > >>>>> Thanks, > >>>>> -Siwei > >>>> People add e.g. new attributes in sysfs left and right. It's unlikely > >>>> to be a matter of serious contention. > >>>> > >>>>>>>> Question is how does userspace know driver isn't broken in this respect? > >>>>>>>> Let's add a "vf failover" flag somewhere so this can be probed? > >>>>>>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org > >>>> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org > >>>> > > > > > -- Respectfully, Sameeh Jubran Linkedin Software Engineer @ Daynix.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]