> -----Original Message----- > From: Jan Scheurich [mailto:[email protected]] > Sent: Thursday, December 7, 2017 4:07 PM > To: Mooney, Sean K <[email protected]>; Kevin Traynor > <[email protected]>; Kavanagh, Mark B <[email protected]>; > Ilya Maximets <[email protected]>; Stokes, Ian > <[email protected]>; [email protected] > Cc: [email protected]; Fischetti, Antonio > <[email protected]>; Bie, Tiwei <[email protected]>; > Mcnamara, John <[email protected]>; Guoshuai Li > <[email protected]>; Loftus, Ciara <[email protected]>; Yuanhan Liu > <[email protected]> > Subject: RE: [ovs-dev] [PATCH V4 2/2] netdev-dpdk: vHost IOMMU support > > > > Would the virtio PMD bug in DPDK 17.11 in the guest actually be > > > mitigated by running DPDK 17.05 or a fixed 17.11.1 as vhostuser > > > backend inside OVS on the host? > > > [Mooney, Sean K] from talking to mark about this eairlier I don’t > belive so. > > I think if you used 17.11 testpmd in the guest with kernel ovs you > > should get the same behavior e.g. it does not forward packet. The > > guest should not be able to know with certainty what vhost backend is > in use on the host. > > If that is the case why should OVS even consider documenting that there > are known problems when running a DPDK 17.11 application in a guest, > irrespective of the OVS version or datapath? > > If anything, this is a critical DPDK bug and DPDK need to warn their > virtio PMD users not to use 17.11 until this bug is fixed in a 17.11.1 > maintenance release. > > The real issue I see is that OVS-DPDK may also be deployed in in a VM > with virtio ports, and that kind of deployment will indeed be broken > with DPDK 17.11. Can we accept and document that as a limitation in OVS > 2.9 that will be fixed in OVS 2.9.1 as soon as DPDK 17.11.1 is out? [Mooney, Sean K] that is a concern for me also. I run ovs-dpdk in a vm on a daily Basis but I typical configure the vm with e1000 virtual nics but that then requires Me to use kernel ovs on the host. I started using this partly to work around old virtio pmd bugs that are have since been fixed.
I ran ovs-dpdk in a vm on top of ovs-dpdk with vhost-user nics via openstack for years However using Virtio-net-pci devices for ovs-dpdk requires special handeling Due to some limitations in the choice of pf driver. Without a virtualized iommu in a guest its not possible to use the vfio-pci Driver with virtio-net-interfaces. qemu/kvm did not support vIOMMUs in the past so this has only recently become an option but I have not validated that it works myself. Uio support is compiled out by default by Ubuntu,fedora,centos and presumable rhel. That mean even on distros that package ovs-dpdk to run it in a vm you have to build From source. Igb_uio was previously known to be buggy with vitio-net-pci devices and dpdk had advised against using it as you could not reliably unbind the virtio interface form igb_uio and back to the kernel driver. So igb_uio worked but you had to reboot the vm to get the kernel dirver working again which was annoying for my development and ci usecases.hence my use of e1000 vNICs This may have been fixed. Uio_pci_generic works with virtio-net-pci devices as far as I know but unlike Vfio-pci or igb_uio its memory access is over privaldged so its not a great choice If you care about you applications security. It did however avoid the buggy igb_uio Rebinding issue and it does not need an iommu to work so has been the most reliable If least secure option for nested ovs-dpdk. Since this bug is in the dpdk virtio pmd and not the pf driver however it will effect Each one equally so I think the onus remain with the vnf vendors that build on ovs and dpdk to validate their dependencies before choosing to rev the ovs and/or dpdk versions they use. Having a warning about this particular issue in the ovs docs however may help some of them Avoid this trap and it will give us something I can refer people to between now and the dpdk 17.11.1 Release. > > Or should we as a temporary solution apply a patch to DPDK 17.11 to fix > this when building OVS? [Mooney, Sean K] dpdk is not built via the ovs make file we just link to it so I don’t think that is a good option for upstream ovs. That said I have patching support In my networking-ovs-dpdk devstack plugin for just this reason. If people are building Ovs form source I think just specifying which dpdk commit fixes the issue should be Enough for them to be able to work around this issue until 17.11.1 is released. > > BR, Jan > > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
