From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: Harry van Haaren <harry.van.haaren@intel.com>
Cc: dev@dpdk.org, thomas.monjalon@6wind.com, hemant.agrawal@nxp.com,
bruce.richardson@intel.com
Subject: Re: [dpdk-dev] [PATCH] doc: add eventdev library to programmers guide
Date: Thu, 30 Mar 2017 19:06:32 +0530 [thread overview]
Message-ID: <20170330133631.kymfnawnzoq7uv7h@localhost.localdomain> (raw)
In-Reply-To: <1489598478-149390-1-git-send-email-harry.van.haaren@intel.com>
On Wed, Mar 15, 2017 at 05:21:18PM +0000, Harry van Haaren wrote:
> This commit adds an entry in the programmers guide
> explaining the eventdev library.
>
> The rte_event struct, queues and ports are explained.
> An API walktrough of a simple two stage atomic pipeline
> provides the reader with a step by step overview of the
> expected usage of the Eventdev API.
Thanks Harry for writing this document.
Overall it looks good.
I have a few thoughts on this document and next steps of eventdev:
1) Need more use cases and associated example applications
The initial version talks only about queue based event pipelining,
I think, we need to add another use case like following in the eventdev
programmers guide with associated example applications.
a) automatic multicore scaling
b) dynamic load balancing,
c) flow based pipelining
d) packet ingress order maintenance
e) synchronization services.
2) ethdev integration is pending.
There are some ethdev(NIC) HW features associated with HW eventdev
implementations. For example, The given example in the programming
guide has dedicated Rx and Tx cores, In HW ethdev and HW eventdev case,
- NIC HW can produce and inject the events to eventdev. No need for
additional Rx core push the data to eventdev on those HW
- In Some NIC HW without SW lock, multiple cores can access the same tx queue
hence the need for additional TX core may not valid on those HW.
IMO, Addressing all the use case with generic example application and
ethdev integration with eventdev would call for minor changes in the
eventdev API and the programmer guide content.
Considering the above points, I would like to share the current
eventdev status and propose the next step for eventdev.
Current eventdev status:
1) Eventdev specification more or less complete
2) Two eventdev driver implementations are ready(completed the review) along
with unit test cases.
a) An eventdev SW driver from Intel
b) An eventdev HW driver from Cavium
Pending work:
1) More generic example applications with additional eventdev uses case
backed by programming guide.
IMO, programming guide will be complete only with generic example
applications.IMHO, we can add the programming guide once we have generic examples
2) Minor change in eventdev specification to accommodate ethdev integration
and example generic application with ethdev and eventdev for packet
forwarding.
If noone is working this, I am planning to work on item 1 and 2 to
complete eventdev work.
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
next prev parent reply other threads:[~2017-03-30 13:36 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 [this message]
2017-03-30 15:59 ` Van Haaren, Harry
2017-03-31 12:43 ` Thomas Monjalon
2017-03-31 13:31 ` Jerin Jacob
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=20170330133631.kymfnawnzoq7uv7h@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).