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

["Richardson, Bruce" <bruce.richardson@intel.com>]

> -----Original Message-----
> From: Neil Horman [mailto:nhorman@tuxdriver.com]
> Sent: Saturday, April 12, 2014 12:03 PM
> To: Thomas Monjalon
> Cc: Richardson, Bruce; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 07/11 1/2] vdev: new registration API
> 
> 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.
> 
The issue with that approach, is how do you create vdevs which are actually backed by physical ethdevs, for example a vdev that is a set of bonded ethdevs e.g. for active/passive failover, or a vdev that actually does post-processing on packets received from a physical ethdev?