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

["John W. Linville" <linville@tuxdriver.com>]

On Mon, Apr 14, 2014 at 03:45:31PM +0200, Thomas Monjalon wrote:
> Hi John,
> 
> 2014-04-14 09:20, John W. Linville:
> > On Sat, Apr 12, 2014 at 08:05:22AM +0200, Thomas Monjalon wrote:
> > > 11/04/2014 20:08, Richardson, Bruce :
> > > > 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?
> > 
> > Treating vdevs as something inherently different from the
> > hardware-backed PMDs continues to be the wrong approach.
> > 
> > Ordinarily the whole point of having an abstraction that looks like
> > a hardware device is so that applications can use either hardware
> > or that abstraction without having to know the difference.  Forcing
> > applications to be vdev-aware defeats the whole purpose of wrapping
> > those constructs inside a PMD in the first place.
> 
> I think there is a misunderstanding here.

So it seems.

> From the user's point of view, it must be possible to create some virtual 
> devices instead of using real ones. That's --vdev option. Then the device is 
> handled as any other one thanks to its PMD.

Except that it isn't, or at least it wasn't -- hence my patch to make
rte_pmd_init_all initialize _all_ PMDs rather than just the hardware
ones.  I hope that will be remedied once all the dust settles with
the patchsets currently in flight.

> From the application's point of view, all devices must be handled with the 
> same API (ethdev). But sometimes, application wants to force creation of 
> virtual devices like pmd_ring. So we need an API for this creation part. Then 
> the device is still handled with the generic ethdev API.
> 
> Do you still see any problem with this approach?
> 
> Hope it's clear.

To me, it seems like a strange thing to do.  But I am ambivalent
about such an API if others want it.

My main concern on this topic is that applications can be blissfully
unaware of whether they are using virtual devices or not.  If someone
actually wants to know about that, then feel free to sell them the rope.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.