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

[Thomas Monjalon <thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>]

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.
>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.
>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.
-- 
Thomas