From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: Harry van Haaren <harry.van.haaren@intel.com>,
dev@dpdk.org, hemant.agrawal@nxp.com, bruce.richardson@intel.com
Subject: Re: [dpdk-dev] [PATCH] doc: add eventdev library to programmers guide
Date: Fri, 31 Mar 2017 19:01:17 +0530 [thread overview]
Message-ID: <20170331133116.2lnwyedslqzvkqfd@localhost.localdomain> (raw)
In-Reply-To: <2350657.jCSKM8N2QJ@xps13>
On Fri, Mar 31, 2017 at 02:43:15PM +0200, Thomas Monjalon wrote:
> 2017-03-30 19:06, Jerin Jacob:
> > 2) ethdev integration is pending.
>
> What is pending exactly?
As a standalone library, Nothing is pending in eventdev.
There are some HW features in the NIC side in some Hardwares that helps
in offloading eventdev related work in NIC. For example,
In the RX side, Some actor is required to inject the events/packets to
eventdev. Some Hardware is capable of offloading that work in NIC.
if that HW feature is not available then core can do the same.
On the TX side, N cores can send the packets to the same TX queue
WITHOUT SW lock. This helps in proper scaling, If that HW feature is not available
in NIC side then core can decide to bind only one tx queue per core.
On the RX side, I don't expect any change in ethdev API.
On the TX side, We may need to have some capability to expose the lock-less
features(I haven't thought about the abstraction details fully).
What I meant by pending here is that, Some future work is required to
enable, abstracting those HW difference and to have portable example
eventdev applications.
>
> [...]
> > Based on the above status, I would like to merge eventdev to DPDK
> > v17.05 with EXPERIMENTAL tag and address pending work in v17.08 and
> > remove the EXPERIMENTAL tag.
> >
> > Thomas and all,
> >
> > Thoughts ?
> >
> > NOTE:
> >
> > Keeping the EXPERIMENTAL status to allow minor change in the API without
> > ABI issue when we address the pending work and I guess NXP eventdev also
> > lined up for v17.08 and they may need a minor change in the API
>
> Yes, generally speaking, it is a good idea to put the experimental tag
> for the first release of an API.
prev parent reply other threads:[~2017-03-31 13:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-15 17:21 Harry van Haaren
2017-03-30 9:14 ` Burakov, Anatoly
2017-03-30 13:36 ` Jerin Jacob
2017-03-30 15:59 ` Van Haaren, Harry
2017-03-31 12:43 ` Thomas Monjalon
2017-03-31 13:31 ` Jerin Jacob [this message]
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=20170331133116.2lnwyedslqzvkqfd@localhost.localdomain \
--to=jerin.jacob@caviumnetworks.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=harry.van.haaren@intel.com \
--cc=hemant.agrawal@nxp.com \
--cc=thomas.monjalon@6wind.com \
/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).