DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Jerin Jacob <jerinjacobk@gmail.com>
Cc: <dev@dpdk.org>, <jerinj@marvell.com>,
	<mattias.ronnblom@ericsson.com>, <abdullah.sevincer@intel.com>,
	<sachin.saxena@oss.nxp.com>, <hemant.agrawal@nxp.com>,
	<pbhagavatula@marvell.com>, <pravin.pathak@intel.com>
Subject: Re: [PATCH v2 11/11] eventdev: RFC clarify docs on event object fields
Date: Thu, 1 Feb 2024 15:24:27 +0000	[thread overview]
Message-ID: <Zbu3q6S3StU-fYNO@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <CALBAE1MHX5QRv1uqV-nSQna477HxKEHd9RVAty-V81_rPcZEHg@mail.gmail.com>

On Thu, Feb 01, 2024 at 08:30:26PM +0530, Jerin Jacob wrote:
> On Thu, Feb 1, 2024 at 3:05 PM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > On Fri, Jan 19, 2024 at 05:43:46PM +0000, Bruce Richardson wrote:
> > > Clarify the meaning of the NEW, FORWARD and RELEASE event types.
> > > For the fields in "rte_event" struct, enhance the comments on each to
> > > clarify the field's use, and whether it is preserved between enqueue and
> > > dequeue, and it's role, if any, in scheduling.
> > >
> > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > ---
> > >
> > > As with the previous patch, please review this patch to ensure that the
> > > expected semantics of the various event types and event fields have not
> > > changed in an unexpected way.
> > > ---
> > >  lib/eventdev/rte_eventdev.h | 105 ++++++++++++++++++++++++++----------
> > >  1 file changed, 77 insertions(+), 28 deletions(-)
> > >
> > <snip>
> >
> > >  #define RTE_EVENT_OP_RELEASE            2
> > >  /**< Release the flow context associated with the schedule type.
> > >   *
> > > - * If current flow's scheduler type method is *RTE_SCHED_TYPE_ATOMIC*
> > > + * If current flow's scheduler type method is @ref RTE_SCHED_TYPE_ATOMIC
> > >   * then this function hints the scheduler that the user has completed critical
> > >   * section processing in the current atomic context.
> > >   * The scheduler is now allowed to schedule events from the same flow from
> > > @@ -1442,21 +1446,19 @@ struct rte_event_vector {
> > >   * performance, but the user needs to design carefully the split into critical
> > >   * vs non-critical sections.
> > >   *
> > > - * If current flow's scheduler type method is *RTE_SCHED_TYPE_ORDERED*
> > > - * then this function hints the scheduler that the user has done all that need
> > > - * to maintain event order in the current ordered context.
> > > - * The scheduler is allowed to release the ordered context of this port and
> > > - * avoid reordering any following enqueues.
> > > - *
> > > - * Early ordered context release may increase parallelism and thus system
> > > - * performance.
> >
> > Before I do up a V3 of this patchset, I'd like to try and understand a bit
> > more what was meant by the original text for reordered here. The use of
> > "context" is very ambiguous, since it could refer to a number of different
> > things here.
> >
> > For me, RELEASE for ordered queues should mean much the same as for atomic
> > queues - it means that the event being released is to be "dropped" from the
> > point of view of the eventdev scheduler - i.e. any atomic locks held for
> > that event should be released, and any reordering slots for it should be
> > skipped. However, the text above seems to imply that when we release one
> > event it means that we should stop reordering all subsequent events for
> > that port - which seems wrong to me. Especially in the case where
> > reordering may be done per flow, does one release mean that we need to go
> > through all flows and mark as skipped all reordered slots awaiting returned
> > events from that port? If this is what is intended, how is it better than
> > just doing another dequeue call from the port, which releases everything
> > automatically anyway?
> >
> > Jerin, I believe you were the author of the original text, can you perhaps
> > clarify? Other PMD maintainers, can any of you chime in with current
> > supported behaviour when enqueuing a release of an ordered event?
> 
> If N number of cores does rte_event_dequeue_burst() and got the same
> flow, and it is scheduled as
> RTE_SCHED_TYPE_ORDERED and then irrespective of the timing downstream
> rte_event_enqueue_burst()
> invocation any core. Upon rte_event_enqueue_burst() completion, the
> events will be enqueued the downstream
> queue in the ingress order.
> 
> Assume, one of the core, calls RTE_EVENT_OP_RELEASE  in between
> dequeue and enqueue, then that event no more
> eligible for the ingress order maintenance.
> 
Thanks for the reply. Just to confirm my understanding - the RELEASE
applies to the event that is being skipped/dropped, which in a burst-mode
of operation i.e. when nb_dequeued > 1, other events may still be enqueued
from that burst and reordered appropriately. Correct?

/Bruce

  reply	other threads:[~2024-02-01 15:24 UTC|newest]

Thread overview: 123+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-18 13:45 [PATCH v1 0/7] improve eventdev API specification/documentation Bruce Richardson
2024-01-18 13:45 ` [PATCH v1 1/7] eventdev: improve doxygen introduction text Bruce Richardson
2024-01-18 13:45 ` [PATCH v1 2/7] eventdev: move text on driver internals to proper section Bruce Richardson
2024-01-18 13:45 ` [PATCH v1 3/7] eventdev: update documentation on device capability flags Bruce Richardson
2024-01-18 13:45 ` [PATCH v1 4/7] eventdev: cleanup doxygen comments on info structure Bruce Richardson
2024-01-18 13:49   ` Bruce Richardson
2024-01-18 13:45 ` [PATCH v1 5/7] eventdev: improve function documentation for query fns Bruce Richardson
2024-01-18 13:45 ` [PATCH v1 6/7] eventdev: improve doxygen comments on configure struct Bruce Richardson
2024-01-18 13:45 ` [PATCH v1 7/7] eventdev: fix documentation for counting single-link ports Bruce Richardson
2024-01-19 17:43 ` [PATCH v2 00/11] improve eventdev API specification/documentation Bruce Richardson
2024-01-19 17:43   ` [PATCH v2 01/11] eventdev: improve doxygen introduction text Bruce Richardson
2024-01-23  8:57     ` Mattias Rönnblom
2024-01-23  9:06       ` Bruce Richardson
2024-01-24 11:37         ` Mattias Rönnblom
2024-01-31 13:45       ` Bruce Richardson
2024-01-19 17:43   ` [PATCH v2 02/11] eventdev: move text on driver internals to proper section Bruce Richardson
2024-01-19 17:43   ` [PATCH v2 03/11] eventdev: update documentation on device capability flags Bruce Richardson
2024-01-23  9:18     ` Mattias Rönnblom
2024-01-23  9:34       ` Bruce Richardson
2024-01-31 14:09       ` Bruce Richardson
2024-02-02  8:58         ` Mattias Rönnblom
2024-02-02 11:20           ` Bruce Richardson
2024-01-19 17:43   ` [PATCH v2 04/11] eventdev: cleanup doxygen comments on info structure Bruce Richardson
2024-01-23  9:35     ` Mattias Rönnblom
2024-01-23  9:43       ` Bruce Richardson
2024-01-24 11:51         ` Mattias Rönnblom
2024-01-31 14:37           ` Bruce Richardson
2024-02-02  9:24             ` Mattias Rönnblom
2024-02-02 10:30               ` Bruce Richardson
2024-01-19 17:43   ` [PATCH v2 05/11] eventdev: improve function documentation for query fns Bruce Richardson
2024-01-23  9:40     ` Mattias Rönnblom
2024-01-19 17:43   ` [PATCH v2 06/11] eventdev: improve doxygen comments on configure struct Bruce Richardson
2024-01-23  9:46     ` Mattias Rönnblom
2024-01-31 16:15       ` Bruce Richardson
2024-01-19 17:43   ` [PATCH v2 07/11] eventdev: fix documentation for counting single-link ports Bruce Richardson
2024-01-23  9:48     ` Mattias Rönnblom
2024-01-23  9:56       ` Bruce Richardson
2024-01-31 16:18         ` Bruce Richardson
2024-01-19 17:43   ` [PATCH v2 08/11] eventdev: improve doxygen comments on config fns Bruce Richardson
2024-01-23 10:00     ` Mattias Rönnblom
2024-01-23 10:07       ` Bruce Richardson
2024-01-19 17:43   ` [PATCH v2 09/11] eventdev: improve doxygen comments for control APIs Bruce Richardson
2024-01-23 10:10     ` Mattias Rönnblom
2024-01-19 17:43   ` [PATCH v2 10/11] eventdev: RFC clarify comments on scheduling types Bruce Richardson
2024-01-23 16:19     ` Mattias Rönnblom
2024-01-24 11:21       ` Bruce Richardson
2024-01-31 17:54       ` Bruce Richardson
2024-01-19 17:43   ` [PATCH v2 11/11] eventdev: RFC clarify docs on event object fields Bruce Richardson
2024-01-24 11:34     ` Mattias Rönnblom
2024-02-01 16:59       ` Bruce Richardson
2024-02-02  9:38         ` Mattias Rönnblom
2024-02-02 11:33           ` Bruce Richardson
2024-02-02 12:02             ` Bruce Richardson
2024-02-01 17:02       ` Bruce Richardson
2024-02-02  9:14         ` Bruce Richardson
2024-02-02  9:22         ` Jerin Jacob
2024-02-02  9:36           ` Bruce Richardson
2024-02-02  9:45         ` Mattias Rönnblom
2024-02-02 10:32           ` Bruce Richardson
2024-02-01  9:35     ` Bruce Richardson
2024-02-01 15:00       ` Jerin Jacob
2024-02-01 15:24         ` Bruce Richardson [this message]
2024-02-01 16:20           ` Jerin Jacob
2024-02-02 12:39   ` [PATCH v3 00/11] improve eventdev API specification/documentation Bruce Richardson
2024-02-02 12:39     ` [PATCH v3 01/11] eventdev: improve doxygen introduction text Bruce Richardson
2024-02-07 10:14       ` Jerin Jacob
2024-02-08  9:50         ` Mattias Rönnblom
2024-02-09  8:43           ` Jerin Jacob
2024-02-10  7:24             ` Mattias Rönnblom
2024-02-20 16:28               ` Bruce Richardson
2024-02-20 16:33         ` Bruce Richardson
2024-02-02 12:39     ` [PATCH v3 02/11] eventdev: move text on driver internals to proper section Bruce Richardson
2024-02-02 12:39     ` [PATCH v3 03/11] eventdev: update documentation on device capability flags Bruce Richardson
2024-02-07 10:30       ` Jerin Jacob
2024-02-20 16:42         ` Bruce Richardson
2024-02-02 12:39     ` [PATCH v3 04/11] eventdev: cleanup doxygen comments on info structure Bruce Richardson
2024-02-02 12:39     ` [PATCH v3 05/11] eventdev: improve function documentation for query fns Bruce Richardson
2024-02-02 12:39     ` [PATCH v3 06/11] eventdev: improve doxygen comments on configure struct Bruce Richardson
2024-02-02 12:39     ` [PATCH v3 07/11] eventdev: improve doxygen comments on config fns Bruce Richardson
2024-02-02 12:39     ` [PATCH v3 08/11] eventdev: improve doxygen comments for control APIs Bruce Richardson
2024-02-02 12:39     ` [PATCH v3 09/11] eventdev: improve comments on scheduling types Bruce Richardson
2024-02-08  9:18       ` Jerin Jacob
2024-02-08 10:04         ` Mattias Rönnblom
2024-02-20 17:23           ` Bruce Richardson
2024-02-02 12:39     ` [PATCH v3 10/11] eventdev: clarify docs on event object fields and op types Bruce Richardson
2024-02-09  9:14       ` Jerin Jacob
2024-02-20 17:39         ` Bruce Richardson
2024-02-21  9:31           ` Jerin Jacob
2024-02-21 10:28             ` Bruce Richardson
2024-02-20 17:50         ` Bruce Richardson
2024-02-20 18:03         ` Bruce Richardson
2024-02-02 12:39     ` [PATCH v3 11/11] eventdev: drop comment for anon union from doxygen Bruce Richardson
2024-02-21 10:32   ` [PATCH v4 00/12] improve eventdev API specification/documentation Bruce Richardson
2024-02-21 10:32     ` [PATCH v4 01/12] eventdev: improve doxygen introduction text Bruce Richardson
2024-02-26  4:51       ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-26  9:59         ` Bruce Richardson
2024-02-29 16:13           ` Jerin Jacob
2024-02-21 10:32     ` [PATCH v4 02/12] eventdev: move text on driver internals to proper section Bruce Richardson
2024-02-26  5:01       ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-21 10:32     ` [PATCH v4 03/12] eventdev: update documentation on device capability flags Bruce Richardson
2024-02-26  5:07       ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-21 10:32     ` [PATCH v4 04/12] eventdev: cleanup doxygen comments on info structure Bruce Richardson
2024-02-26  5:18       ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-21 10:32     ` [PATCH v4 05/12] eventdev: improve function documentation for query fns Bruce Richardson
2024-02-26  5:18       ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-21 10:32     ` [PATCH v4 06/12] eventdev: improve doxygen comments on configure struct Bruce Richardson
2024-02-26  6:36       ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-21 10:32     ` [PATCH v4 07/12] eventdev: improve doxygen comments on config fns Bruce Richardson
2024-02-26  6:43       ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-26  6:44         ` Pavan Nikhilesh Bhagavatula
2024-02-21 10:32     ` [PATCH v4 08/12] eventdev: improve doxygen comments for control APIs Bruce Richardson
2024-02-26  6:44       ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-21 10:32     ` [PATCH v4 09/12] eventdev: improve comments on scheduling types Bruce Richardson
2024-02-26  6:49       ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-21 10:32     ` [PATCH v4 10/12] eventdev: clarify docs on event object fields and op types Bruce Richardson
2024-02-26  6:52       ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-21 10:32     ` [PATCH v4 11/12] eventdev: drop comment for anon union from doxygen Bruce Richardson
2024-02-26  6:52       ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-21 10:32     ` [PATCH v4 12/12] eventdev: fix doxygen processing of event vector struct Bruce Richardson
2024-02-26  6:53       ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-03-04 15:35       ` Thomas Monjalon
2024-03-04 15:49         ` Bruce Richardson
2024-02-23 12:36     ` [PATCH v4 00/12] improve eventdev API specification/documentation 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=Zbu3q6S3StU-fYNO@bricha3-MOBL.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=abdullah.sevincer@intel.com \
    --cc=dev@dpdk.org \
    --cc=hemant.agrawal@nxp.com \
    --cc=jerinj@marvell.com \
    --cc=jerinjacobk@gmail.com \
    --cc=mattias.ronnblom@ericsson.com \
    --cc=pbhagavatula@marvell.com \
    --cc=pravin.pathak@intel.com \
    --cc=sachin.saxena@oss.nxp.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).