On 4/2/20 1:13 PM, Noa Ezra wrote: > Introduce dpdkvdpa netdev allowing HW offloads over VirtIO network > devices. > > dpdkvdpa ports can be added to netdev bridges with the following > command: > ovs-vsctl add-port br0 vdpa0 -- set Interface vdpa0 type=dpdkvdpa > options:vdpa-socket-path=<sock path> > options:vdpa-accelerator-devargs=<VF pci id> > options:dpdk-devargs=<pf pci id>,representor=[id] > options:vdpa-max-queues=<num of queues> > vdpa-max-queues is an optional field. > > vDPA netdev is designed to support both SW and HW acceleration. > SRIOV capable NICs can use the SW acceleration which relays packets > between VF and virtIO ports. > In a future patch, a support for vDPA configuration will be added, > so that HW mode will configure vDPA capable NICs.
I've spent some time last month researching what was done and what efforts are currently in progress around vDPA and here is what I learned: The main approach from the kernel side is to provide vhost-vdpa device for applications. This device might be used by DPDK applications via virtio-user or by qemu as a vhost backend for virtio device in guest and there might be virtio network interface and, probably, vfio support on host if needed in the future. The idea behind vDPA is that datapath is direct between the application and physical device. Control path at the moment might be implemented via DPDK or via kernel vDPA frameworks. Since there is no real performance difference between using one or another vDPA framework, kernel framework is preferable, because it provides better service in terms that we don't need to run any special userspace application just to handle control path and no need to work with special virtio-user sockets for that purpose. DPDK vDPA framework considered as a testing tool to make users familiar with vDPA technology without need to update their kernel or wait for virtio-user to support all the required ioctl calls. Kernel vDPA framework will be a choice for real vDPA integration. Saying that, there is no need to integrate real vDPA DPDK framework into OVS, because of its testing purposes. And at this point without integration of real vDPA devices there is no point of this fake vDPA a.k.a. virtio-forwarder ports. There is a separate virtio-forwarding solution that is even already integrated in OpenStack. And there is an ongoing work on DPDK vDPA daemon that will work as a control path provider for the transition/evaluation time. Best regards, Ilya Maximets. > > The dpdkvdpa netdev supports all kind of traffic (TCP, UDP, NFV etc). > > Using dpdkvdpa port allows to forward packets between VF and VirtIO guests > with better performance than using standard VirtIO ports. > On the first scenario, a guest is connected to OVS using VirtIO. > On the second scenario, a guest is connected to OVS using dpdkvdpa port. > The guest is running testpmd. > A Traffic generator (iperf3 or Ixia) is sending packets to the OVS. > In this case, dpdkvdpa port improves the performance by ~35%. > > https://travis-ci.org/github/noaezra/OVS/builds/670001370 > > Patch 1 provides the vdpa functionality as a pre-step without a functional > change. > Patch 2 introduces the dpdkvdpa vport. > > > Noa Ezra (2): > netdev-dpdk-vdpa: Introduce dpdkvdpa netdev > netdev-dpdk: Add dpdkvdpa port > > Documentation/automake.mk | 1 + > Documentation/topics/dpdk/index.rst | 1 + > Documentation/topics/dpdk/vdpa.rst | 90 ++++ > NEWS | 1 + > lib/automake.mk | 4 +- > lib/netdev-dpdk-vdpa.c | 820 > ++++++++++++++++++++++++++++++++++++ > lib/netdev-dpdk-vdpa.h | 55 +++ > lib/netdev-dpdk.c | 164 +++++++- > vswitchd/vswitch.xml | 25 ++ > 9 files changed, 1159 insertions(+), 2 deletions(-) > create mode 100644 Documentation/topics/dpdk/vdpa.rst > create mode 100755 lib/netdev-dpdk-vdpa.c > create mode 100644 lib/netdev-dpdk-vdpa.h > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
