From: "Wiles, Keith" <keith.wiles@intel.com>
To: "Richardson, Bruce" <bruce.richardson@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC PATCHv2 0/2] pktdev as wrapper type
Date: Wed, 20 May 2015 00:19:27 +0000 [thread overview]
Message-ID: <D1814B44.208E5%keith.wiles@intel.com> (raw)
In-Reply-To: <20150519113112.GA10700@bricha3-MOBL3>
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
next prev parent reply other threads:[~2015-05-20 0:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-11 16:29 Bruce Richardson
2015-05-11 16:29 ` [dpdk-dev] [RFC PATCHv2 1/2] Add example pktdev implementation Bruce Richardson
2015-05-11 16:29 ` [dpdk-dev] [RFC PATCHv2 2/2] example app showing pktdevs used in a chain Bruce Richardson
2015-05-19 11:31 ` [dpdk-dev] [RFC PATCHv2 0/2] pktdev as wrapper type Bruce Richardson
2015-05-20 0:19 ` Wiles, Keith [this message]
2015-05-20 8:31 ` Thomas Monjalon
2015-05-20 10:05 ` Marc Sune
2015-05-20 10:28 ` Neil Horman
2015-05-20 17:01 ` Marc Sune
2015-05-20 18:47 ` Neil Horman
2015-05-21 12:12 ` Richardson, Bruce
2015-06-10 13:07 ` [dpdk-dev] [RFC-PATCH-v3 0/6] pktdev update Bruce Richardson
2015-06-10 13:07 ` [dpdk-dev] [RFC-PATCH-v3 1/6] kni: add function to query the name of a kni object Bruce Richardson
2015-06-10 13:07 ` [dpdk-dev] [RFC-PATCH-v3 2/6] pktdev: Add pktdev implementation library Bruce Richardson
2015-06-10 13:07 ` [dpdk-dev] [RFC-PATCH-v3 3/6] example app showing pktdevs used in a chain Bruce Richardson
2015-06-10 13:07 ` [dpdk-dev] [RFC-PATCH-v3 4/6] new pktdev l2fwd sample Bruce Richardson
2015-06-10 13:07 ` [dpdk-dev] [RFC-PATCH-v3 5/6] pktdev: adding app test Bruce Richardson
2015-06-10 13:07 ` [dpdk-dev] [RFC-PATCH-v3 6/6] test: add pktdev performance tests Bruce Richardson
2015-06-10 13:26 ` [dpdk-dev] [RFC-PATCH-v3 0/6] pktdev update Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D1814B44.208E5%keith.wiles@intel.com \
--to=keith.wiles@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).