DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jerin Jacob <jerinjacobk@gmail.com>
To: Abdullah Sevincer <abdullah.sevincer@intel.com>
Cc: dev@dpdk.org, jerinj@marvell.com, bruce.richardson@intel.com,
	 pravin.pathak@intel.com, mattias.ronnblom@ericsson.com,
	 manish.aggarwal@intel.com
Subject: Re: [PATCH v3 2/2] eventdev: add support for enqueue reorder
Date: Mon, 24 Jun 2024 13:58:09 +0530	[thread overview]
Message-ID: <CALBAE1Orr_N4kJ+iuSkrNH=AgSLFvbxxFzd4b3SJhCMPBib9xg@mail.gmail.com> (raw)
In-Reply-To: <20240621222408.583464-3-abdullah.sevincer@intel.com>

On Sat, Jun 22, 2024 at 4:02 AM Abdullah Sevincer
<abdullah.sevincer@intel.com> wrote:
>
> This commit adds support flag to enable enqueue reorder
> feature.
>
> When this flag is enabled in the port configuration PMD
> restores dequeue order on enqueue if applications happen to
> change it.
>
> Signed-off-by: Abdullah Sevincer <abdullah.sevincer@intel.com>
> ---
>  lib/eventdev/rte_eventdev.h | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
> index 08e5f9320b..f4220dd5dc 100644
> --- a/lib/eventdev/rte_eventdev.h
> +++ b/lib/eventdev/rte_eventdev.h
> @@ -1073,6 +1073,14 @@ rte_event_queue_attr_set(uint8_t dev_id, uint8_t queue_id, uint32_t attr_id,
>   *  @see rte_event_port_setup()
>   */
>
> +#define RTE_EVENT_PORT_CFG_RESTORE_DEQ_ORDER   (1ULL << 5)
> +/**< Flag to enable feature enqueue reordering to dequeue.
> + * The feature restores dequeue order on enqueue if applications
> + * happen to change the order.

# Is this feature or limitation?
# What is the use case for this feature?
# If application don't care about ORDER, they can use
RTE_SCHED_TYPE_PARALLEL. Right?
# Can you share the feature in the context of the below text in specification?

----------------
/* Scheduler type definitions */
#define RTE_SCHED_TYPE_ORDERED          0
/**< Ordered scheduling
 *
 * Events from an ordered flow of an event queue can be scheduled to multiple
 * ports for concurrent processing while maintaining the original event order,
 * i.e. the order in which they were first enqueued to that queue.
 * This scheme allows events pertaining to the same, potentially large, flow to
 * be processed in parallel on multiple cores without incurring any
 * application-level order restoration logic overhead.
 *
 * After events are dequeued from a set of ports, as those events are
re-enqueued
 * to another queue (with the op field set to @ref
RTE_EVENT_OP_FORWARD), the event
 * device restores the original event order - including events returned from all
 * ports in the set - before the events are placed on the destination queue,
 * for subsequent scheduling to ports

-----------------


> + *
> + *  @see rte_event_port_setup()
> + */
> +
>  /** Event port configuration structure */
>  struct rte_event_port_conf {
>         int32_t new_event_threshold;
> --
> 2.25.1
>

  reply	other threads:[~2024-06-24  8:28 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-21 20:12 [PATCH v1 0/2] DLB Enqueue Reorder Support Abdullah Sevincer
2024-06-21 20:12 ` [PATCH v1 1/2] event/dlb2: add support for enqueue reordering Abdullah Sevincer
2024-06-21 20:51   ` [PATCH v2 0/2] DLB Enqueue Reorder Support Abdullah Sevincer
2024-06-21 20:51     ` [PATCH v2 1/2] event/dlb2: add support for enqueue reordering Abdullah Sevincer
2024-06-21 20:51     ` [PATCH v2 2/2] eventdev: add support for enqueue reorder Abdullah Sevincer
2024-06-21 22:24   ` [PATCH v3 0/2] DLB Enqueue Reorder Support Abdullah Sevincer
2024-06-21 22:24     ` [PATCH v3 1/2] event/dlb2: add support for enqueue reordering Abdullah Sevincer
2024-06-21 22:24     ` [PATCH v3 2/2] eventdev: add support for enqueue reorder Abdullah Sevincer
2024-06-24  8:28       ` Jerin Jacob [this message]
2024-06-26 18:31         ` Sevincer, Abdullah
2024-06-27 13:13           ` Jerin Jacob
2024-07-01  8:24       ` Mattias Rönnblom
2024-07-01  8:50       ` Mattias Rönnblom
2024-07-02 17:25         ` Pathak, Pravin
2024-06-21 20:12 ` [PATCH v1 " Abdullah Sevincer

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='CALBAE1Orr_N4kJ+iuSkrNH=AgSLFvbxxFzd4b3SJhCMPBib9xg@mail.gmail.com' \
    --to=jerinjacobk@gmail.com \
    --cc=abdullah.sevincer@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=jerinj@marvell.com \
    --cc=manish.aggarwal@intel.com \
    --cc=mattias.ronnblom@ericsson.com \
    --cc=pravin.pathak@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).