DPDK patches and discussions
 help / color / mirror / Atom feed
From: Srikanth Yalavarthi <syalavarthi@marvell.com>
Cc: <dev@dpdk.org>, <aprabhu@marvell.com>, <syalavarthi@marvell.com>,
	<sshankarnara@marvell.com>, <ptakkar@marvell.com>,
	<jerinj@marvell.com>
Subject: [PATCH 00/11] Introduce Event ML Adapter
Date: Sun, 7 Jan 2024 07:34:39 -0800	[thread overview]
Message-ID: <20240107153454.3909-1-syalavarthi@marvell.com> (raw)

Machine learning event adapter library
======================================

DPDK Eventdev library provides event driven programming model with features to schedule
events. ML Device library provides an interface to ML poll mode drivers that support
Machine Learning inference operations. Event ML Adapter is intended to bridge between
the event device and the ML device.

Packet flow from ML device to the event device can be accomplished using software and hardware
based transfer mechanisms. The adapter queries an eventdev PMD to determine which mechanism to
be used. The adapter uses an EAL service core function for software based packet transfer and
uses the eventdev PMD functions to configure hardware based packet transfer between ML device
and the event device.

The application can choose to submit a ML operation directly to an ML device or send it to the ML
adapter via eventdev based on RTE_EVENT_ML_ADAPTER_CAP_INTERNAL_PORT_OP_FWD capability. The first
mode is known as the event new (RTE_EVENT_ML_ADAPTER_OP_NEW) mode and the second as the event
forward (RTE_EVENT_ML_ADAPTER_OP_FORWARD) mode. The choice of mode can be specified while
creating the adapter. In the former mode, it is an application responsibility to enable ingress
packet ordering. In the latter mode, it is the adapter responsibility to enable the ingress
packet ordering.


Working model of RTE_EVENT_ML_ADAPTER_OP_NEW mode:

               +--------------+         +--------------+
               |              |         |   ML stage   |
               | Application  |---[2]-->| + enqueue to |
               |              |         |     mldev    |
               +--------------+         +--------------+
                   ^   ^                       |
                   |   |                      [3]
                  [6] [1]                      |
                   |   |                       |
               +--------------+                |
               |              |                |
               | Event device |                |
               |              |                |
               +--------------+                |
                      ^                        |
                      |                        |
                     [5]                       |
                      |                        v
               +--------------+         +--------------+
               |              |         |              |
               |  ML adapter  |<--[4]---|    mldev     |
               |              |         |              |
               +--------------+         +--------------+


        [1] Application dequeues events from the previous stage.
        [2] Application prepares the ML operations.
        [3] ML operations are submitted to mldev by application.
        [4] ML adapter dequeues ML completions from mldev.
        [5] ML adapter enqueues events to the eventdev.
        [6] Application dequeues from eventdev for further processing.

In the RTE_EVENT_ML_ADAPTER_OP_NEW mode, application submits ML operations directly to ML device.
The ML adapter then dequeues ML completions from ML device and enqueue events to the event
device. This mode does not ensure ingress ordering, if the application directly enqueues to mldev
without going through ML / atomic stage i.e. removing item [1] and [2].

Events dequeued from the adapter will be treated as new events. In this mode, application needs
to specify event information (response information) which is needed to enqueue an event after the
ML operation is completed.


Working model of RTE_EVENT_ML_ADAPTER_OP_FORWARD mode:

               +--------------+         +--------------+
       --[1]-->|              |---[2]-->|  Application |
               | Event device |         |      in      |
       <--[8]--|              |<--[3]---| Ordered stage|
               +--------------+         +--------------+
                   ^      |
                   |     [4]
                  [7]     |
                   |      v
              +----------------+       +--------------+
              |                |--[5]->|              |
              |   ML adapter   |       |     mldev    |
              |                |<-[6]--|              |
              +----------------+       +--------------+


        [1] Events from the previous stage.
        [2] Application in ordered stage dequeues events from eventdev.
        [3] Application enqueues ML operations as events to eventdev.
        [4] ML adapter dequeues event from eventdev.
        [5] ML adapter submits ML operations to mldev (Atomic stage).
        [6] ML adapter dequeues ML completions from mldev
        [7] ML adapter enqueues events to the eventdev
        [8] Events to the next stage

In the event forward (RTE_EVENT_ML_ADAPTER_OP_FORWARD) mode, if the HW supports the capability
RTE_EVENT_ML_ADAPTER_CAP_INTERNAL_PORT_OP_FWD, application can directly submit the ML operations
to the mldev. If not, application retrieves the event port of the ML adapter through the API,
rte_event_ml_adapter_event_port_get(). Then, links its event queue to this port and starts
enqueuing ML operations as events to the eventdev. The adapter then dequeues the events and
submits the ML operations to the mldev. After the ML completions, the adapter enqueues events to
the event device.

Application can use this mode, when ingress packet ordering is needed. Events dequeued from the
adapter will be treated as forwarded events. In this mode, the application needs to specify the
mldev ID and queue pair ID (request information) needed to enqueue an ML operation in addition to
the event information (response information) needed to enqueue an event after the ML operation
has completed.

The event ML adapter provides common APIs to configure the packet flow from the ML device to
event devices for both SW and HW based transfers. The ML event adapter's functions are:

 - rte_event_ml_adapter_create_ext()
 - rte_event_ml_adapter_create()
 - rte_event_ml_adapter_free()
 - rte_event_ml_adapter_queue_pair_add()
 - rte_event_ml_adapter_queue_pair_del()
 - rte_event_ml_adapter_start()
 - rte_event_ml_adapter_stop()
 - rte_event_ml_adapter_stats_get()
 - rte_event_ml_adapter_stats_reset()

The application creates an instance using rte_event_ml_adapter_create() or
rte_event_ml_adapter_create_ext().

mldev queue pair addition / deletion is done using the rte_event_ml_adapter_queue_pair_add() /
rte_event_ml_adapter_queue_pair_del() APIs. If HW supports the capability
RTE_EVENT_ML_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND, event information must be passed to the add
API.

Srikanth Yalavarthi (11):
  eventdev: introduce ML event adapter library
  event/ml: add ml adapter capabilities get
  event/ml: add adapter create and free
  event/ml: add adapter port get
  event/ml: add adapter queue pair add and delete
  event/ml: add support for service function
  event/ml: add adapter start and stop
  event/ml: add support to get adapter service ID
  event/ml: add support for runtime params
  event/ml: add adapter stats functions
  event/ml: implement adapter enqueue

 MAINTAINERS                                   |    6 +
 config/rte_config.h                           |    1 +
 doc/api/doxy-api-index.md                     |    1 +
 doc/guides/prog_guide/event_ml_adapter.rst    |  268 ++++
 doc/guides/prog_guide/eventdev.rst            |   10 +-
 .../img/event_ml_adapter_op_forward.svg       | 1086 +++++++++++++
 .../img/event_ml_adapter_op_new.svg           | 1079 +++++++++++++
 doc/guides/prog_guide/index.rst               |    1 +
 lib/eventdev/eventdev_pmd.h                   |  170 ++
 lib/eventdev/eventdev_private.c               |   10 +
 lib/eventdev/meson.build                      |    4 +-
 lib/eventdev/rte_event_ml_adapter.c           | 1375 +++++++++++++++++
 lib/eventdev/rte_event_ml_adapter.h           |  594 +++++++
 lib/eventdev/rte_eventdev.c                   |   27 +
 lib/eventdev/rte_eventdev.h                   |   45 +
 lib/eventdev/rte_eventdev_core.h              |    8 +-
 lib/meson.build                               |    2 +-
 lib/mldev/rte_mldev.h                         |    6 +
 18 files changed, 4685 insertions(+), 8 deletions(-)
 create mode 100644 doc/guides/prog_guide/event_ml_adapter.rst
 create mode 100644 doc/guides/prog_guide/img/event_ml_adapter_op_forward.svg
 create mode 100644 doc/guides/prog_guide/img/event_ml_adapter_op_new.svg
 create mode 100644 lib/eventdev/rte_event_ml_adapter.c
 create mode 100644 lib/eventdev/rte_event_ml_adapter.h

-- 
2.42.0


             reply	other threads:[~2024-01-07 15:35 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-07 15:34 Srikanth Yalavarthi [this message]
2024-01-07 15:34 ` [PATCH 01/11] eventdev: introduce ML event adapter library Srikanth Yalavarthi
2024-02-02  8:51   ` Jerin Jacob
2024-02-07  9:17   ` Naga Harish K, S V
2024-01-07 15:34 ` [PATCH 02/11] event/ml: add ml adapter capabilities get Srikanth Yalavarthi
2024-01-07 15:34 ` [PATCH 03/11] event/ml: add adapter create and free Srikanth Yalavarthi
2024-01-07 15:34 ` [PATCH 04/11] event/ml: add adapter port get Srikanth Yalavarthi
2024-01-07 15:34 ` [PATCH 05/11] event/ml: add adapter queue pair add and delete Srikanth Yalavarthi
2024-01-07 15:34 ` [PATCH 06/11] event/ml: add support for service function Srikanth Yalavarthi
2024-01-07 15:34 ` [PATCH 07/11] event/ml: add adapter start and stop Srikanth Yalavarthi
2024-01-07 15:34 ` [PATCH 08/11] event/ml: add support to get adapter service ID Srikanth Yalavarthi
2024-01-07 15:34 ` [PATCH 09/11] event/ml: add support for runtime params Srikanth Yalavarthi

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=20240107153454.3909-1-syalavarthi@marvell.com \
    --to=syalavarthi@marvell.com \
    --cc=aprabhu@marvell.com \
    --cc=dev@dpdk.org \
    --cc=jerinj@marvell.com \
    --cc=ptakkar@marvell.com \
    --cc=sshankarnara@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).