DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: dev@dpdk.org
Subject: Re: [dpdk-dev] [RFC PATCHv2 0/2] pktdev as wrapper type
Date: Tue, 19 May 2015 12:31:12 +0100	[thread overview]
Message-ID: <20150519113112.GA10700@bricha3-MOBL3> (raw)
In-Reply-To: <1431361781-12621-1-git-send-email-bruce.richardson@intel.com>

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

  parent reply	other threads:[~2015-05-19 11:31 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 ` Bruce Richardson [this message]
2015-05-20  0:19   ` [dpdk-dev] [RFC PATCHv2 0/2] pktdev as wrapper type Wiles, Keith
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=20150519113112.GA10700@bricha3-MOBL3 \
    --to=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).