Re: [dpdk-dev] [dpdk-announce] DPDK Features for Q1 2015

["O'driscoll, Tim" <tim.o'driscoll@intel.com>]

> From: Matthew Hall [mailto:mhall@mhcomputing.net]
> 
> On Wed, Oct 22, 2014 at 01:48:36PM +0000, O'driscoll, Tim wrote:
> > Single Virtio Driver: Merge existing Virtio drivers into a single
> > implementation, incorporating the best features from each of the
> > existing drivers.
> 
> Specifically, in the virtio-net case above, I have discovered, and Sergio at Intel
> just reproduced today, that neither virtio PMD works at all inside of
> VirtualBox. One can't init, and the other gets into an infinite loop. But yet it's
> claiming support for VBox on the DPDK Supported NICs page though it
> doesn't seem it ever could have worked.

At the moment, within Intel we test with KVM, Xen and ESXi. We've never tested with VirtualBox. So, maybe this is an error on the Supported NICs page, or maybe somebody else is testing that configuration.

> So I'd like to request an initiative alongside any virtio-net and/or vmxnet3
> type of changes, to make some kind of a Virtualization Test Lab, where we
> support VMWare ESXi, QEMU, Xen, VBox, and the other popular VM
> systems.
> 
> Otherwise it's hard for us community / app developers to make the DPDK
> available to end users in simple, elegant ways, such as packaging it into
> Vagrant VM's, Amazon AMI's etc. which are prebaked and ready-to-run.

Expanding the scope of virtualization testing is a good idea, especially given industry trends like NFV. We're in the process of getting our DPDK Test Suite ready to push to dpdk.org soon. The hope is that others will use it to validate changes they're making to DPDK, and contribute test cases so that we can build up a more comprehensive set over time.

One area where this does need further work is in virtualization. At the moment, our virtualization tests are manual, so they won't be included in the initial DPDK Test Suite release. We will look into automating our current virtualization tests and adding these to the test suite in future.

> Another thing which would help in this area would be additional
> improvements to the NUMA / socket / core / number of NICs / number of
> queues autodetections. To write a single app which can run on a virtual card,
> a hardware card without RSS available, and a hardware card with RSS
> available, in a thread-safe, flow-safe way, is somewhat complex at the
> present time.
> 
> I'm running into this in the VM based environments because most VNIC's
> don't have RSS and it complicates the process of keeping consistent state of
> the flows among the cores.

This is interesting. Do you have more details on what you're thinking here, that perhaps could be used as the basis for an RFC?


Tim