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

[Neil Horman]

On Sat, Apr 12, 2014 at 11:23:50AM +0000, Richardson, Bruce wrote:
> 
> 
> > -----Original Message-----
> > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > Sent: Saturday, April 12, 2014 12:03 PM
> > To: Thomas Monjalon
> > Cc: Richardson, Bruce; dev at 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?
> 
I'm not sure I see your point, or more specifically how it relates to what we're
discussing here.  All I'm suggesting is that, instead of exposing two functions
( rte_eth_ring_pair_create and rte_eth_ring_pair_attach ), we call them from
within the pmd init routine, encoding the parameters to pass to the functions as
arguments to the --vdev command line option.  If you plan to do other things
between those two calls, then what you problably want is to add an ioctl type
interface (or perhaps some other dev-specific type of type-checked interface)
that is implemented in the rte_ethdev api, to let you call down to the pmd
without needing to link directly to it.  If you're hope is to back ethdevs into
bonded configurations, that definately seems to be the sort of thing for which
you need additional infrastructure code, and possibly a bonded pmd (like the
bonding driver in the linux kernel).  Either way, I'm not sure I see the
relation to doing such things, and hiding direct linkage of pmd defined
functions to an application.

Regards
Neil