[dpdk-dev] [RFC PATCHv2 0/2] pktdev as wrapper type
Wiles, Keith
keith.wiles at intel.com
Wed May 20 02:19:27 CEST 2015
It looks fine to me.
On 5/19/15, 7:31 AM, "Richardson, Bruce" <bruce.richardson at 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
More information about the dev
mailing list