[dpdk-dev] [PATCH 0/3] ring: provide rte_ring_as_ethdev API

[Neil Horman]

On Mon, May 19, 2014 at 10:59:18AM +0000, Richardson, Bruce wrote:
> 
> 
> > -----Original Message-----
> > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > Sent: Friday, May 16, 2014 7:54 PM
> > To: Richardson, Bruce
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 0/3] ring: provide rte_ring_as_ethdev API
> > 
> > On Fri, May 16, 2014 at 07:15:11PM +0100, Bruce Richardson wrote:
> > >
> > NAK, I don't think this makes sense.  If you want to encapsulate a ring pair as
> > an ethdev, then write a pmd that does so.  That will give you a standardized
> > ethdev that you can create using the existing --vdev librte_eal command line
> > options without having to widen your API surface, or having to write
> > applications that specifically know about the fact that your ethdev is composed
> > of rings under the covers.
> > 
> 
> The objective is not to "encapsulate a ring pair", but instead allow a ring to be "type-cast" to an ethdev for the purposes of rx and tx. 
Thats semantics.  Whatever you want to call it, you're goal is to treat a ring
pair like an ethernet interface.  You already have a mechanism to do that,
librte_pmd_ring.

> If this is provided, we can provide standard functions which work to take packets in using rx_burst and which send packets out after processing using tx_burst. The same code can then be used unmodified without worrying about whether the packets come from/to a NIC or from another core (via ring).
Again, you can already do this, librte_pmd_ring.  You're re-inventing the wheel.

If what you want is the ability to dynamically take a ring that you've created
and use it interchangeably as a ring and an ethernet device, I would suggest one
of the following:

1) Create a loopback PMD that registers a port, where anything transmitted to it
is immediately recieved on it again.  This allows you to reuse the existing
rte_eth_* api entirely to accomplish what you need

2) Create a tap device library and PMD, akin to the linux Tun/Tap device driver.
This is some additional work of course, and still expands the api, but does so
in a controlled and generic manner, useful to other applications.  By that I
mean that other data sources besides librte_ring can be used to feed data into
the network stack (pcap files or port mirroring applications, etc).

Either way, what you have right now is doing little more than solving a generic
problem only for one data source, in a way that unnecessecarily expands the API
surface.

Neil