DPDK patches and discussions
 help / color / mirror / Atom feed
From: "O'driscoll, Tim" <tim.o'driscoll@intel.com>
To: Matthew Hall <mhall@mhcomputing.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [dpdk-announce] DPDK Features for Q1 2015
Date: Fri, 24 Oct 2014 08:10:40 +0000	[thread overview]
Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA54C42AEE@IRSMSX102.ger.corp.intel.com> (raw)
In-Reply-To: <20141022192219.GB10424@mhcomputing.net>

> 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

  reply	other threads:[~2014-10-24  8:02 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-22 13:48 O'driscoll, Tim
2014-10-22 14:20 ` [dpdk-dev] " Thomas Monjalon
2014-10-22 14:44   ` Zhou, Danny
2014-10-22 15:05     ` Liang, Cunming
2014-10-22 16:10 ` [dpdk-dev] [dpdk-announce] " Luke Gorrie
2014-10-23 12:29   ` O'driscoll, Tim
2014-10-22 19:22 ` Matthew Hall
2014-10-24  8:10   ` O'driscoll, Tim [this message]
2014-10-24 10:10     ` Thomas Monjalon
2014-10-24 19:02       ` Matthew Hall
2014-10-24 19:01     ` Matthew Hall
2014-10-23  3:06 ` Tetsuya Mukawa
2014-10-23 10:04   ` O'driscoll, Tim
2014-10-23  3:17 ` Tetsuya Mukawa
2014-10-23 11:27   ` O'driscoll, Tim
2014-10-31 22:05   ` Xie, Huawei
2014-11-02 12:50     ` Tetsuya Mukawa
2014-10-23 14:18 ` [dpdk-dev] Fwd: " Jay Rolette
2014-10-23 14:52   ` Alex Markuze

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=26FA93C7ED1EAA44AB77D62FBE1D27BA54C42AEE@IRSMSX102.ger.corp.intel.com \
    --to=tim.o'driscoll@intel.com \
    --cc=dev@dpdk.org \
    --cc=mhall@mhcomputing.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).