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

Richardson, Bruce bruce.richardson at intel.com
Fri Apr 11 22:08:10 CEST 2014


> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> Sent: Friday, April 11, 2014 6:45 PM
> To: Thomas Monjalon
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 07/11 1/2] vdev: new registration API
> 
> On Fri, Apr 11, 2014 at 06:18:08PM +0200, Thomas Monjalon wrote:
> > 2014-04-11 11:50, Neil Horman:
> >
> > 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.

Regards,
/Bruce


More information about the dev mailing list