[dpdk-dev] [PATCH v2 07/11 1/2] vdev: new registration API

[Neil Horman]

On Sat, Apr 12, 2014 at 08:05:22AM +0200, Thomas Monjalon wrote:
> Hi Bruce,
> 
> 11/04/2014 20:08, Richardson, Bruce :
> > From: Neil Horman
> > > On Fri, Apr 11, 2014 at 06:18:08PM +0200, Thomas Monjalon wrote:
> > > > It seems that your patch is not removing
> > > > rte_eth_ring_pair_create/rte_eth_ring_pair_attach so I'm not sure you
> > > > can dynamically change the PMD in this case.
> > > 
> > > Ew, I had missed those calls.  Yes, those should be encapsulated as some
> > > driver ops or some such.  I'll look at that when I rebase.  Regardless
> > > however, I didn't mean to state that pmds could be switched while
> > > running, only that the pmd to use could be specified at run time. 
> > > Though, you're correct, pmd_ring doesn't seem to hold in line with the
> > > other pmds in their isolation.
> > 
> > The ring PMD is probably best treated separately from the other PMDs as it's
> > not really a device poll-mode driver. Instead, it's a general library that
> > presents an API to make a ring, or set of rings, appear as a poll-mode
> > driver ethdev. The EAL command to have one created at startup time was just
> > an addon after-the-fact in case someone might find it useful :-). However,
> > it's primary purpose was to allow applications to be written which could
> > use physical NICs or rings interchangeably. For example, an app with
> > multiple stages in a pipeline, where each stage just reads from an ethdev
> > without caring if it's actually reading from a port or from packets sent
> > from another lcore/function etc. Another example might be where an
> > application wishes to sometimes loop packets back to itself, in this case
> > it uses the C API to create an additional ring ethdev which it uses as
> > output port for any packets it wants looped back - no special handling
> > needed, everything is an ethdev to it on which it calls rx_burst or
> > tx_burst. It's also likely that in future we will develop other libraries
> > which wish to present their functionality via rx_burst/tx_burst functions
> > i.e. as an ethdev.
> 
> I think you are describing a vdev and you want to be able to instantiate this 
> vdev in your application code. Right?
> So why not make a generic API to be able to instantiate a vdev?
> 
+1, thats exactly what you're describing richard, an ethernet device thats
backed by rings (or pipes, or whatever other non-phycial transport you want to
use).  Though we already have a method to generically instantiate a vdev, its
the --vdev option in the eal library.  It seems to me the simplest solution here
is to remove the ring_create/attach api from public accessibility, and call it
directly from the pmd init routine by passing parameters to it through the
--vdev command line argument.  I've actually got that in the patch series that
I'm rebasing for the PMD DSO cleanups.

Neil

> -- 
> Thomas
>