[ovs-dev] [PATCH V6 1/2] netdev-dpdk: DPDK v17.11 upgrade

Jan Scheurich jan.scheurich at ericsson.com
Fri Dec 8 15:18:25 UTC 2017


> >
> >What happened to my request to add here that running OVS 2.9 with DPDK
> >datapath in a VM with virtio interfaces may itself suffer from the DPDK 17.11
> >bug in OVS' own virtio PMD? The work-around for this could be to enable the
> >mrg_rxbuf feature in Qemu for the OVS VM as that would trigger OVS to not use
> >vector rx.
> >
> >This is essentially different from the note in the vhost_user section below
> >that talks about DPDK apps running in a guest VM served by OVS.
> 
> I see - I actually didn't get that from your initial mail, but your point is clear now.
> Technically, OvS is still a DPDK app in the guest using the virtio PMD, so it would fall under the caveats in this patch regarding guest DPDK
> apps. However, I see no harm in calling out OvS in the guest specifically.

>From OVS perspective I would say "guest" is an OS + application in a VM connected to OVS through vhost or vhostuser ports.

Not being able to run OVS-DPDK in a VM is a limitation of OVS itself. I would not look for a warning in the vhost_user documentation.

> >> +.. important::
> >> +
> >> +  DPDK v17.11 virtio PMD contains a bug in the vectorized Rx function that
> >> +  affects testpmd/DPDK guest applications. As such, guest DPDK applications
> >> +  should use a non-vectorized Rx function.
> >> +
> >> +The DPDK v17.11 virtio net driver contains a bug that prevents guest DPDK
> >> +applications from receiving packets when the vectorized Rx function is
> >used.
> >> +This only occurs when guest-bound traffic is live before a DPDK application
> >is
> >> +started within the guest, and where two or more forwarding cores are used.
> >As
> >> +such, it is not recommended for guests which execute DPDK applications to
> >use
> >> +the virtio vectorized Rx function. A simple method of ensuring that a non-
> >> +vectorized Rx function is used is to enable mergeable buffers for the
> >guest,
> >> +with the following QEMU command line option::
> >> +
> >> +    mrg_rxbuf=on
> >
> >For an arbitrary DPDK application in the guest that may not solve the issue!
> >Where or not mergeable Rx buffers are negotiated to be used depends on two
> >things: 1. Support enabled in Qemu, 2. Support signaled in the guest virtio
> >driver and 3. Support signaled in the vhostuser backend.
> >
> 
> If I'm not mistaken, your primary concern expressed in the three numbered points above is that if the version of DPDK in the guest does
> not support signaling of mergeable buffer support in both the virtio driver and vhostuser backend, then the vectorized Rx function is still a
> possibility (point 1. is irrelevant, since QEMU v2.7.0 and up - prerequisites for vhost user client ports - support mergerable buffers). Would
> your concerns be alleviated if a particular known 'good' version of DPDK was specified here? (v17.05.2, for example).

I don't want to complicate things. Actually I would prefer not to discuss this aspect of the DPDK bug in OVS documentation at all!

If I, as an OVS user, need to host a VM with an application built against the buggy DPDK 17.11, I can go and ask the supplier to fix it by building against 17.05.2 or against the 17.11.1 release when it comes.

I think it is in general impossible to force the application to not use vector rx by enabling mrg_rxbuf on the Qemu cmdline because the application may choose to ignore that and disable mrg_rxbuf anyhow. Perhaps removing some other pre-requisite for the bug, like disabling vhost multi-queue might help.

It is only in the special case that the OVS user is also building the VM herself (e.g. as a test tool) that she has a chance to correct the bug by patching DPDK or building with 17.05.2. The latter would be trivial for DPDK test apps like testpmd or pktgen. In other cases it might require application fixes due the incompatible ABI changes.

BR, Jan


More information about the dev mailing list