From patchwork Tue Aug 1 07:00:15 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Srikanth Yalavarthi X-Patchwork-Id: 5 Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4B8C442F95; Tue, 1 Aug 2023 09:00:26 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 24E0D40A7D; Tue, 1 Aug 2023 09:00:26 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by mails.dpdk.org (Postfix) with ESMTP id 58A67400D5 for ; Tue, 1 Aug 2023 09:00:25 +0200 (CEST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3712rQYl021923 for ; Tue, 1 Aug 2023 00:00:24 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=pfpt0220; bh=CgrtB+EU48ypduVL0HMDBfP7hnHHRk6yjLbo2/MYhqk=; b=UOwctqDXg915783DKTmm2Na1a1PKrPfj5DxQ9V5fn8l8mYHKP3ew+ftoTNk76CrwQKOx h9mX8Lse3xVUbj98RB2KTk8ZicogGpDNOksQtqWruZQDQi1oh2v0pzlrRgYPlN89bhCm 0kIOF14kndc6hfSz5QjumHHyzQLDdkxKiLMRYVrKNkxTsf/BFNtg+6xBxrVtBmhyFWkR qf1DxFlqe22AGw7sLqdkwgceC98kNiO1AJpd+8UJpGT8fpuyc++R9erXqaQ8zogzRpg8 fRxhrXkEqrcWliKPcszjNnvb5pEZg2jLTEvkYAKQMKGcIoW2WeIFPZMi8eZ6L76Pz267 tg== Received: from dc5-exch02.marvell.com ([199.233.59.182]) by mx0a-0016f401.pphosted.com (PPS) with ESMTPS id 3s6du0b84y-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 01 Aug 2023 00:00:24 -0700 Received: from DC5-EXCH02.marvell.com (10.69.176.39) by DC5-EXCH02.marvell.com (10.69.176.39) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Tue, 1 Aug 2023 00:00:22 -0700 Received: from maili.marvell.com (10.69.176.80) by DC5-EXCH02.marvell.com (10.69.176.39) with Microsoft SMTP Server id 15.0.1497.48 via Frontend Transport; Tue, 1 Aug 2023 00:00:22 -0700 Received: from ml-host-33.caveonetworks.com (unknown [10.110.143.233]) by maili.marvell.com (Postfix) with ESMTP id DCCD33F7053; Tue, 1 Aug 2023 00:00:21 -0700 (PDT) From: Srikanth Yalavarthi To: CC: , , , , , Subject: [RFC PATCH v2 0/1] Introduce Event ML Adapter Date: Tue, 1 Aug 2023 00:00:15 -0700 Message-ID: <20230801070016.340-1-syalavarthi@marvell.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20230423041227.22036-1-syalavarthi@marvell.com> References: <20230423041227.22036-1-syalavarthi@marvell.com> MIME-Version: 1.0 X-Proofpoint-GUID: 7TbzOAvDsLBNLemLXg1euNav8yg1J_QI X-Proofpoint-ORIG-GUID: 7TbzOAvDsLBNLemLXg1euNav8yg1J_QI X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-08-01_03,2023-07-31_02,2023-05-22_02 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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. Contents of RFC --------------- This RFC attempts to define standard APIs for: 1) New event type for ML operations. 2) Definition of mode of operations for the adapter. 3) Definition of functions to handle ML event adapter, which includes fetching capabilities, adapter initialization and termination, managing adapter queue-pairs and retrieving adapter stats. Roadmap ------- 1) Address the comments for this RFC. 2) Common code for eventdev. 3) ML adapter driver for cn10k. 4) Add support for ML adapter in app/test-eventdev application. Srikanth Yalavarthi (1): eventdev: introduce ML event adapter library 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 | 8 +- .../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/meson.build | 4 +- lib/eventdev/rte_event_ml_adapter.c | 6 + lib/eventdev/rte_event_ml_adapter.h | 594 +++++++++ lib/eventdev/rte_eventdev.h | 45 + lib/meson.build | 2 +- lib/mldev/rte_mldev.h | 6 + 14 files changed, 3102 insertions(+), 5 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