From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: "Vangati, Narender" <narender.vangati@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>, "Eads, Gage" <gage.eads@intel.com>
Subject: Re: [dpdk-dev] [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK
Date: Wed, 2 Nov 2016 14:29:27 +0530 [thread overview]
Message-ID: <20161102085925.GA25740@localhost.localdomain> (raw)
In-Reply-To: <20161028141617.GA97736@bricha3-MOBL3.ger.corp.intel.com>
On Fri, Oct 28, 2016 at 03:16:18PM +0100, Bruce Richardson wrote:
> On Fri, Oct 28, 2016 at 02:48:57PM +0100, Van Haaren, Harry wrote:
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> > > Sent: Tuesday, October 25, 2016 6:49 PM
> > <snip>
> > >
> > > Hi Community,
> > >
> > > So far, I have received constructive feedback from Intel, NXP and Linaro folks.
> > > Let me know, if anyone else interested in contributing to the definition of eventdev?
> > >
> > > If there are no major issues in proposed spec, then Cavium would like work on
> > > implementing and up-streaming the common code(lib/librte_eventdev/) and
> > > an associated HW driver.(Requested minor changes of v2 will be addressed
> > > in next version).
> >
> >
> > Hi All,
> >
> > I've been looking at the eventdev API from a use-case point of view, and I'm unclear on a how the API caters for two uses. I have simplified these as much as possible, think of them as a theoretical unit-test for the API :)
> >
> >
> > Fragmentation:
> > 1. Dequeue 8 packets
> > 2. Process 2 packets
> > 3. Processing 3rd, this packet needs fragmentation into two packets
> > 4. Process remaining 5 packets as normal
> >
> > What function calls does the application make to achieve this?
> > In particular, I'm referring to how can the scheduler know that the 3rd packet is the one being fragmented, and how to keep packet order valid.
> >
> >
> > Dropping packets:
> > 1. Dequeue 8 packets
> > 2. Process 2 packets
> > 3. Processing 3rd, this packet needs to be dropped
> > 4. Process remaining 5 packets as normal
> >
> > What function calls does the application make to achieve this?
> > Again, in particular how does the scheduler know that the 3rd packet is being dropped.
> >
> >
> > Regards, -Harry
>
> Hi,
>
> these questions apply particularly to reordered which has a lot more
> complications than the other types in terms of sending packets back into
> the scheduler. However, atomic types will still suffer from problems
> with things the way they are - again if we assume a burst of 8 packets,
> then to forward those packets, we need to re-enqueue them again to the
> scheduler, and also then send 8 releases to the scheduler as well, to
> release the atomic locks for those packets.
> This means that for each packet we have to send two messages to a
> scheduler core, something that is really inefficient.
>
> This number of messages is critical for any software implementation, as
> the cost of moving items core-to-core is going to be a big bottleneck
> (perhaps the biggest bottleneck) in the system. It's for this reason we
> need to use burst APIs - as with rte_rings.
I agree, That the reason why we have rte_event_*_burst()
>
> How we have solved this in our implementation, is to allow there to be
> an event operation type. The four operations we implemented are as below
> (using packet as a synonym for event here, since these would mostly
> apply to packets flowing through a system):
>
> * NEW - just a regular enqueue of a packet, without any previous context
Makes sense. I was trying derive it.Make sense for application
requesting it.
> * FORWARD - enqueue a packet, and mark the flow processing for the
> equivalent packet that was dequeued as completed, i.e.
> release any atomic locks, or reorder this packet with
> respect to any other outstanding packets from the event queue.
Default case
> * DROP - this is roughtly equivalent to the existing "release" API call,
> except that having it as an enqueue type allows us to
> release multiple items in a single call, and also to mix
> releases with new packets and forwarded packets
Yes. Maps to rte_event_release(), with index parameter, its kind doing
the job. But, Makes sense as flag to enable burst.
But it calls for removing the index parameter. Looks like index parameter
has issue in Intel implementation. If so, may be we(Cavium) can fill the
index in the dequeue as implementation specific bits like Harry
suggested and use it in enqueue.
http://dpdk.org/ml/archives/dev/2016-October/049459.html
Any thoughts from NXP?
> * PARTIAL - this indicates that the packet being enqueued should be
> treated according to the context of the current packet, but
> that that context should not be released/completed by the
> enqueue of this packet. This only really applies for
> reordered events, and is needed to do fragmentation and or
> multicast of packets with reordering.
I believe PARTIAL is something, HW implementation will have trouble.
I have outlined other way to fix without coupling fragmentation logic in
scheduler.
http://dpdk.org/ml/archives/dev/2016-November/049707.html
If it makes sense for everyone then may be can
- Introduce "event operation type" bits (NEW, DROP, FORWARD(may not required as it is default) in enqueue
- remaining bits in "struct rte_event"(128B) for "implementation" defined
- remove rte_event_release() and use event operation type(DROP) as
replacement.
/Jerin
>
>
> Therefore, I think we need to use some of the bits just freed up in the
> event structure to include an enqueue operation type. Without it, I just
> can't see how the API can ever support burst operation on packets.
>
> Regards,
> /Bruce
>
next prev parent reply other threads:[~2016-11-02 8:59 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-04 21:49 [dpdk-dev] [RFC] " Vangati, Narender
2016-10-05 7:24 ` Jerin Jacob
2016-10-07 10:40 ` Hemant Agrawal
2016-10-09 8:27 ` Jerin Jacob
2016-10-11 19:30 ` [dpdk-dev] [RFC] [PATCH v2] " Jerin Jacob
2016-10-14 4:14 ` Bill Fischofer
2016-10-14 9:26 ` Jerin Jacob
2016-10-14 10:30 ` Hemant Agrawal
2016-10-14 12:52 ` Jerin Jacob
2016-10-14 15:00 ` Eads, Gage
2016-10-17 4:18 ` Jerin Jacob
2016-10-17 20:26 ` Eads, Gage
2016-10-18 11:19 ` Jerin Jacob
2016-10-14 16:02 ` Bruce Richardson
2016-10-17 5:10 ` Jerin Jacob
2016-10-25 17:49 ` Jerin Jacob
2016-10-26 12:11 ` Van Haaren, Harry
2016-10-26 12:24 ` Jerin Jacob
2016-10-26 12:54 ` Bruce Richardson
2016-10-28 3:01 ` Jerin Jacob
2016-10-28 8:36 ` Bruce Richardson
2016-10-28 9:06 ` Jerin Jacob
2016-11-02 11:25 ` Jerin Jacob
2016-11-02 11:35 ` Bruce Richardson
2016-11-02 13:09 ` Jerin Jacob
2016-11-02 13:56 ` Bruce Richardson
2016-11-02 14:54 ` Jerin Jacob
2016-10-26 18:37 ` Vincent Jardin
2016-10-28 13:10 ` Van Haaren, Harry
2016-11-02 10:47 ` Jerin Jacob
2016-11-02 11:45 ` Bruce Richardson
2016-11-02 12:34 ` Jerin Jacob
2016-10-26 12:43 ` Bruce Richardson
2016-10-26 17:30 ` Jerin Jacob
2016-10-28 13:48 ` Van Haaren, Harry
2016-10-28 14:16 ` Bruce Richardson
2016-11-02 8:59 ` Jerin Jacob [this message]
2016-11-02 8:06 ` Jerin Jacob
2016-11-02 11:48 ` Bruce Richardson
2016-11-02 12:57 ` Jerin Jacob
2016-10-14 15:00 Francois Ozog
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=20161102085925.GA25740@localhost.localdomain \
--to=jerin.jacob@caviumnetworks.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=gage.eads@intel.com \
--cc=narender.vangati@intel.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).