Re: [dpdk-dev] [RFC PATCH 0/4] pktdev

[Neil Horman <nhorman@tuxdriver.com>]

On Fri, Apr 17, 2015 at 04:16:40PM +0100, Bruce Richardson wrote:
> Hi all,
> 
> to continue this discussion a bit more, here is my, slightly different, slant
> on what a pktdev abstraction may look like.
> 
> The primary objective I had in mind when drafting this is to provide the 
> minimal abstraction that can be *easily* used as a common device abstraction for
> existing (and future) device types to be passed to dataplane code. The patchset
> demonstrates this by defining a minimal interface for pktdev - since I firmly
> believe the interface should be as small as possible - and then showing how that
> common interface can be used to unify rings and ethdevs under a common API for the
> datapath. I believe any attempt to unify things much beyond this to the control
> plane or setup phase is not worth doing - at least not initially - as at 
> init time the code always needs to be aware of the underlying resource type in
> order to configure it properly for dataplane use.
> 
> The overall objective I look to achieve is illustrated by the final patch in
> the series, which is a sample app where the same code is used for all cores,
> irrespective of the underlying device type.
> 
> To get to that point, patch 1 defines the minimal API - just RX and TX. The .c
> file in the library is empty for simplicity, though I would see some
> functionality moving there when/if it makes sense e.g. the callback support
> from ethdev, as is done in Keith's patchset.
> Patch 2 then makes very minimal changes to ethdev to allow ethdevs to be used
> as pktdevs, and to make use of the pktdev functions when appropriate
> Patch 3 was, for me, the key test for this implementation - how hard was it to
> make an rte_ring usable as a pktdev too. Two single-line functions for RX/TX
> and a separate "converter" function proved to be all that was necessary here -
> and I believe simpler solutions may be possible too, as the extra structures
> allocated on conversion could be merged into the rte_ring structure itself and
> initialized on ring creation if we prefer that option. It is hoped/presumed that
> wrapping other structures, such as KNI, may prove to be just as easily done.
> [Not attempted yet - left as an exercise for the reader :-)].
> 
> Now, in terms of pktdev vs ethdev, there is nothing in this proposal that
> cannot also be done using ethdev AFAIK. However, pktdev as outlined here
> should make the process far easier than trying to create a full PMD for something.
> All NIC specific functions, including things like stop/start, are stripped out,
> as they don't make sense for an rte_ring or other software objects.
> Also, the other thing this provides is that we can move away from just using
> port ids. Instead in the same way as we now reference rings/mempools/KNIs etc
> via pointer, we can do the same with ethernet ports as pktdevs on the data path.
> There was discussion previously on moving beyond 8-bit port ids. If we look to
> use ethdev as a common abstraction, I feel that change will soon have to be made
> causing a large amount of code churn.
> 
This is the thing that I think we are really disagreeing on here.  The ease of
use increase.  As you claim above, theres nothing you can do with a pktdev that
you can't do with an ethdev, so why not just use an ethdev?  Its no more
difficult, the API already exists and contains checks so that any ethdev method
that is unimplemented just return EOPNOTSUPP.   Its a well understood model,
just use it.

Neil