DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Mattias Rönnblom" <hofors@lysator.liu.se>
To: pbhagavatula@marvell.com, jerinj@marvell.com,
	sthotton@marvell.com, abdullah.sevincer@intel.com,
	hemant.agrawal@nxp.com, sachin.saxena@oss.nxp.com,
	harry.van.haaren@intel.com, mattias.ronnblom@ericsson.com,
	liangma@liangbit.com, peter.mccarthy@intel.com
Cc: dev@dpdk.org
Subject: Re: [RFC 0/3] Introduce event prefetching
Date: Tue, 10 Sep 2024 11:08:44 +0200	[thread overview]
Message-ID: <586afa56-d51d-47f2-abea-e9f23d9b90a5@lysator.liu.se> (raw)
In-Reply-To: <20240910083117.4281-1-pbhagavatula@marvell.com>

On 2024-09-10 10:31, pbhagavatula@marvell.com wrote:
> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
> 
> Event prefetching improves scheduling performance by pre-scheduling events to
> event ports when dequeues are issued. This series introduces various types and
> levels of prefetching to the eventdev library.
> 

I would avoid to use the term "prefetch", since that word is used for 
manual (software) prefetching (preloading in ARM speak). In particular, 
since having the event device prefetch future event-related data may 
potentially also be interesting to do (i.e., to have an option to 
prefetch user-configurable lines in the buffer pointed to by a future 
event).

I suggest RTE_EVENT_DEV_PRESCHEDULE*.

If you make prescheduling a hint, you don't need the capability flags, 
and no error handling. Much smaller API, less fuzz for the application.

> Prefetching Types:
>   * RTE_EVENT_DEV_PREFETCH_NONE: No prefetching.
>   * RTE_EVENT_DEV_PREFETCH: Always issue a prefetch when dequeue is issued.
>   * RTE_EVENT_DEV_PREFETCH_INTELLIGENT: Delay issuing prefetch until there
>     are no forward progress constraints with the held flow contexts.
> 

Maybe RTE_EVENT_DEV_PREFETCH_ADAPTIVE is better. I suggest that being 
the default. In that case, for event devices which can't preschedule or 
which always (by design) have to preschedule, can continue doing what 
they are doing and still calling this "adaptive".

RTE_EVENT_DEV_PREFETCH_AUTO would also work.

Setting aside the complexity issue, prescheduling hints or configuration 
seems like a valuable feature to include in the Eventdev API.

> Prefetching Levels:
>   * Event Device Level Prefetch: Prefetching can be enabled or disabled at the
>     event device during configuration. Event devices can indicate prefetching
>     capabilities using `RTE_EVENT_DEV_CAP_EVENT_PREFETCH` and
>    `RTE_EVENT_DEV_CAP_EVENT_INTELLIGENT_PREFETCH` via the event device info
>    function `info.event_dev_cap`.
>   * Event Port Level Prefetch: Prefetching can be selectively enabled or disabled
>     at the event port during runtime. Event devices can indicate this capability
>     using `RTE_EVENT_PORT_CAP_EVENT_PER_PORT_PREFETCH` via the event device info
>     function `info.event_port_cap`.
>   * Application Controlled Prefetch Hint: Applications can provide hints to the
>     event device to start prefetching events using the new API
>     `rte_event_port_prefetch`. Event devices can indicate this capabilities using
>     `RTE_EVENT_DEV_CAP_SW_PREFETCH` via the event device info function
>     `info.event_dev_cap`.
> 
> The rte_event_dequeue_burst operation initiates the prefetch operation, which
> completes in parallel without affecting the dequeued event flow context and
> dequeue latency. On the next dequeue operation, the prefetched events are
> dequeued, and prefetch is initiated again.
> 
> In the case of application-controlled prefetch hints, the currently held flow
> contexts, if any, are not affected by the prefetch operation. On the next
> dequeue operation, the prefetched events are returned, but prefetch is not
> initiated again until the application provides the hint again. If prefetching
> is already enabled at the event device level or event port level,
> the hint is ignored.
> 
> Pavan Nikhilesh (3):
>    eventdev: introduce event prefetching
>    eventdev: allow event ports to modified prefetches
>    eventdev: add SW event prefetch hint
> 
>   app/test/test_eventdev.c                    | 113 +++++++++++++++
>   doc/guides/prog_guide/eventdev/eventdev.rst |  42 ++++++
>   lib/eventdev/eventdev_pmd.h                 |   4 +
>   lib/eventdev/eventdev_private.c             |  19 +++
>   lib/eventdev/eventdev_trace_points.c        |   6 +
>   lib/eventdev/rte_eventdev.h                 | 152 ++++++++++++++++++++
>   lib/eventdev/rte_eventdev_core.h            |   9 ++
>   lib/eventdev/rte_eventdev_trace_fp.h        |  19 ++-
>   lib/eventdev/version.map                    |   6 +
>   9 files changed, 369 insertions(+), 1 deletion(-)
> 
> --
> 2.46.0

  parent reply	other threads:[~2024-09-10  9:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-10  8:31 pbhagavatula
2024-09-10  8:31 ` [RFC 1/3] eventdev: introduce " pbhagavatula
2024-09-10  8:31 ` [RFC 2/3] eventdev: allow event ports to modified prefetches pbhagavatula
2024-09-10  8:31 ` [RFC 3/3] eventdev: add SW event prefetch hint pbhagavatula
2024-09-10  9:08 ` Mattias Rönnblom [this message]
2024-09-10 11:53   ` [EXTERNAL] Re: [RFC 0/3] Introduce event prefetching Pavan Nikhilesh Bhagavatula
2024-09-17  7:11 ` [PATCH v2 0/3] Introduce event pre-scheduling pbhagavatula
2024-09-17  7:11   ` [PATCH v2 1/3] eventdev: introduce " pbhagavatula
2024-09-18 22:38     ` Pathak, Pravin
2024-09-19 13:13       ` Pavan Nikhilesh Bhagavatula
2024-09-17  7:11   ` [PATCH v2 2/3] eventdev: add event port pre-schedule modify pbhagavatula
2024-09-17  7:11   ` [PATCH v2 3/3] eventdev: add SW event preschedule hint pbhagavatula

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=586afa56-d51d-47f2-abea-e9f23d9b90a5@lysator.liu.se \
    --to=hofors@lysator.liu.se \
    --cc=abdullah.sevincer@intel.com \
    --cc=dev@dpdk.org \
    --cc=harry.van.haaren@intel.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=jerinj@marvell.com \
    --cc=liangma@liangbit.com \
    --cc=mattias.ronnblom@ericsson.com \
    --cc=pbhagavatula@marvell.com \
    --cc=peter.mccarthy@intel.com \
    --cc=sachin.saxena@oss.nxp.com \
    --cc=sthotton@marvell.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).