Re: [dpdk-dev] [RFC PATCHv2 0/2] pktdev as wrapper type

[Thomas Monjalon <thomas.monjalon@6wind.com>]

2015-05-19 12:31, Bruce Richardson:
> On Mon, May 11, 2015 at 05:29:39PM +0100, Bruce Richardson wrote:
> > Hi all,
> > 
> > after a small amount of offline discussion with Marc Sune, here is an
> > alternative proposal for a higher-level interface - aka pktdev - to allow a
> > common Rx/Tx API across device types handling mbufs [for now, ethdev, ring
> > and KNI]. The key code is in the first patch fo the set - the second is an
> > example of a trivial usecase.
> > 
> > What is different about this to previously:
> > * wrapper class, so no changes to any existing ring, ethdev implementations
> > * use of function pointers for RX/TX with an API that maps to ethdev
> >   - this means there is little/no additional overhead for ethdev calls
> >   - inline special case for rings, to accelerate that. Since we are at a 
> >     higher level, we can special case process some things if appropriate. This
> >     means the impact to ring ops is one (predictable) branch per burst
> > * elimination of the queue abstraction. For the ring and KNI, there is no
> >   concept of queues, so we just wrap the functions directly (no need even for
> >   wrapper functions, the api's match so we can call directly). This also
> >   means:
> >   - adding in features per-queue, is far easier as we don't need to worry about
> >     having arrays of multiple queues. For example:
> >   - adding in buffering on TX (or RX) is easier since again we only have a 
> >     single queue.
> > * thread safety is made easier using a wrapper. For a MP ring, we can create
> >   multiple pktdevs around it, and each thread will then be able to use their
> >   own copy, with their own buffering etc.
> > 
> > However, at this point, I'm just looking for general feedback on this as an
> > approach. I think it's quite flexible - even more so than the earlier proposal
> > we had. It's less proscriptive and doesn't make any demands on any other libs.
> > 
> > Comments/thoughts welcome.
> 
> Any comments on this RFC before I see about investing further time in it to clean
> it up a bit and submit as a non-RFC patchset for merge in 2.1?

I would say there are 2 possible approaches for KNI and ring handling:
1/ You Bruce, Marc and Keith are advocating for a layer on top of ethdev,
ring, KNI and possibly other devices, which uses mbuf. The set of functions
is simpler than ethdev but the data structure is mbuf which is related to
ethdev layer.
2/ Konstantin and Neil talked about keeping mbuf for ethdev layer and related
libs only. Ring and KNI could have an ethdev API with a reduced set of
implemented functions. Crypto devices could adopt a specific crypto API and
an ethdev API at the same time.

I feel it's cleaner, more generic and more maintainable to have drivers
implementing one or several stable APIs instead of having some restricted
wrappers to update.

Comments are welcome.