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

["Wiles, Keith" <keith.wiles@intel.com>]

It looks fine to me.

On 5/19/15, 7:31 AM, "Richardson, Bruce" <bruce.richardson@intel.com>
wrote:

>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.
>> 
>> Bruce Richardson (2):
>>   Add example pktdev implementation
>>   example app showing pktdevs used in a chain
>>
>
>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?
>
>/Bruce