From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id D4FF3A0548; Sat, 3 Apr 2021 14:32:14 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5CE8A40696; Sat, 3 Apr 2021 14:32:14 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mails.dpdk.org (Postfix) with ESMTP id 491F04067B for ; Sat, 3 Apr 2021 14:32:12 +0200 (CEST) IronPort-SDR: znYuAxSqE08NGyQuU0SjAeyofJZT+tWGF1N3XLuK6dChpBvxyOQnEF+yub2GD45QwVj2jMJKKj xKiOO9chR2Kg== X-IronPort-AV: E=McAfee;i="6000,8403,9942"; a="179736325" X-IronPort-AV: E=Sophos;i="5.81,302,1610438400"; d="scan'208";a="179736325" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2021 05:32:10 -0700 IronPort-SDR: ig9lfQ7XFipH3m2pHP7krnmm8EiwwIRDU9haXk4rNPDI0q8qkjxQWsoLS7xktqJvmvlz7OI8ee 59NPyLgr+YTQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.81,302,1610438400"; d="scan'208";a="447235918" Received: from fmsmsx606.amr.corp.intel.com ([10.18.126.86]) by fmsmga002.fm.intel.com with ESMTP; 03 Apr 2021 05:32:10 -0700 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) by fmsmsx606.amr.corp.intel.com (10.18.126.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Sat, 3 Apr 2021 05:32:10 -0700 Received: from fmsmsx604.amr.corp.intel.com (10.18.126.84) by fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Sat, 3 Apr 2021 05:32:09 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx604.amr.corp.intel.com (10.18.126.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2 via Frontend Transport; Sat, 3 Apr 2021 05:32:09 -0700 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.43) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2106.2; Sat, 3 Apr 2021 05:32:09 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cX1om5XFGoLWGTguBzADzzBN5qF76PVCGbvtbGrp2iJGTg16D9dPKf4STIFXIKOqS4HoxZGo0nTljI0ORgIQWQCCfdBbTPgza+onh+kvhbYlWWidL8CjZULX1b0MPnD7Yrpx7wi+1eg5DyRYDXIejbqu1MkSuTyx14pM2KpOggxY5+ouSkgfiFrxRBfx78RYIfdo1zOuT4GyGvn2JsdISxm0X/ITdShZlEJeY7u8xH4/ArOGx8ssWq6pe/bae++XVTFDMI9HhyFd2tsHX2hDxCzyotnJ2pFL9BPNbqtA5mjyH8Qc2YR9s0lsoap95op0Pf3V+VTLz6jgfmuWFlY96w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ydSoOOGG7QBsmaz2OEVKpj9zvkI4rLrGgnyfvLD9ws0=; b=F8e/AEv3XsBqnd7hsjunMtUuxY0H1BtWRrJl5r6WVIjOByf4NNc7xa+opVA0GdPGmVR2pFgui3GPGjpeVnsSPJjHMgg0B57UDvUvepORE5Ru+cZvciQ3sWA9NfFTRryKW3B9rG2FzlnrgDxRDfkW81s96D7acrWDaYhku3wlgXx+Cno+PjFTwcEgzcS2FicH73i+mq7Iin9XOxs0V7E4Eueo7O+hfVS66/4wCEaQCKX3r8WVNZPxXqRtPBFiANGVIJfES0fCAY8pTTrC3vkoZ9Imdh8+tXZzxWH8BjPsHOy/+dy4BydYU1Og3mj+ngKxwuyJLumm35oXhFSKkbTkyw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ydSoOOGG7QBsmaz2OEVKpj9zvkI4rLrGgnyfvLD9ws0=; b=N0zr4b8bXjTRVKB4WI5n3z8w+ngV7ohUa1DQDZqOTH3XKg6H6yiQtdAudfMBj5is5FrTvZNzRnyILyNSCczIaPZuWDTS4NrfmWK69QwXGK1xHR/ynXbrhiUFgyrntZNLmAP4XGW7wZpqsU7K5EqKzrpmTOYo+xpL6ZO7EbCQqTE= Received: from DM6PR11MB3548.namprd11.prod.outlook.com (2603:10b6:5:143::18) by DM6PR11MB3724.namprd11.prod.outlook.com (2603:10b6:5:13c::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.29; Sat, 3 Apr 2021 12:32:08 +0000 Received: from DM6PR11MB3548.namprd11.prod.outlook.com ([fe80::1952:a31:a852:cf70]) by DM6PR11MB3548.namprd11.prod.outlook.com ([fe80::1952:a31:a852:cf70%4]) with mapi id 15.20.3955.033; Sat, 3 Apr 2021 12:32:08 +0000 From: "Gujjar, Abhinandan S" To: Shijith Thotton , "dev@dpdk.org" CC: Akhil Goyal , "thomas@monjalon.net" , "jerinj@marvell.com" , "hemant.agrawal@nxp.com" , "nipun.gupta@nxp.com" , "sachin.saxena@oss.nxp.com" , "anoobj@marvell.com" , "matan@nvidia.com" , "Zhang, Roy Fan" , "g.singh@nxp.com" , "Carrillo, Erik G" , "Jayatheerthan, Jay" , "pbhagavatula@marvell.com" , "Van Haaren, Harry" Thread-Topic: [PATCH v4 1/3] eventdev: introduce crypto adapter enqueue API Thread-Index: AQHXJ+InK6Y4FrRP00+Yc7oWy8t5OqqisAQw Date: Sat, 3 Apr 2021 12:32:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: marvell.com; dkim=none (message not signed) header.d=none;marvell.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [103.5.135.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 73e20a46-a79f-4b97-91a6-08d8f69c7f52 x-ms-traffictypediagnostic: DM6PR11MB3724: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: c++wMlLLooOF8yQ9nIC/PswE/KV6tomjupnN/GT5aOSE672L9GMP7CgJm1Eoxmio6RJwV8il9T9OmaclbqO/6b4YOnbAGwoWGeFRwMYYqeCHJkcbRAAvNq5F4aQP1hrEVf4o4qAkd21dTDy/yAOGmITAWecL0k6E0Puu7FeaakYSHaI6iQ2i49Vpo/vfAiaIFZgTZMl7qZM5uMi3IPrrwa+qT/JMnnaebtMmnnVWzErlfEq4j55SRM39zEdjNZPEwvYE6+f+JjGeHEbq7xl1ySAw6X6cdrsEXWhScmthlitO+z3G4H+6KGI7mX0DGXblhazpnOfxXN95tIPPRQphXB5k/ShPLtlkIwOzbO2nd/Mhu3S7twxUqmoefKpovQzXrQVtw//BYY7SdoL9Z7HBTSpZyG/qXT58sYdx4ajMIbe8Vm5UpzoS0uKQ6uKT2J6rK4ebTTgCd2NBWE4a/WWaK9sgI5oqmuBipHri3Kc0O1EOTcIVn9TV2ltwBNPCjyfPCO+zCsgpiYYbefksqVuJ7K2pHaUkNsm9KvOAGDuXqGaYf3QiGD45x/30f96YntvIUXEyE1eHkK9/x0GLmDkDunfS1+iKQXC/fbRuIvhXsPI4WSucwyHerodxfZtRjMWTMxbe0z6KgFHjINTqdtgFDnLHAbRXWpLhgO94agxuVl8= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3548.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(376002)(346002)(136003)(396003)(366004)(7696005)(52536014)(66556008)(38100700001)(478600001)(86362001)(66946007)(110136005)(54906003)(55236004)(7416002)(4326008)(186003)(83380400001)(6506007)(316002)(107886003)(8676002)(53546011)(26005)(33656002)(55016002)(71200400001)(76116006)(2906002)(9686003)(66476007)(8936002)(64756008)(66446008)(5660300002)(30864003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?t+tocNYJkkwWU3ZohEpnal5+8O9ngNz95Q4wq/tksTTsvpak7S+Si5+QhFpy?= =?us-ascii?Q?pI5v/v4MzoHM0KfqoQidnmU4sXXeGDpJe3UeOLUHeZgiyaj4QjdrH8hLNTLH?= =?us-ascii?Q?He0WBuUi/CJ3YxCJizJ5ac4BsbywEVVCJO/qJmztthGuDtOpfCaXYhbsGVZw?= =?us-ascii?Q?1Mibs2pAh8g6v9g05mmMVsUmjs/4CojFkE1H4Be2DCpY/H15IzlC5xfRzg9i?= =?us-ascii?Q?Wccp1MYWwLEsivdj3+Z8yu/MKljQlBDlc27Vp4Mdw8SqQBq4nOrMQlxp/45H?= =?us-ascii?Q?aHgqRJkQ79xITmSn3O39WRXSgG3qnACjlunmDvsFzxmGfTumGHFMni0rM3KA?= =?us-ascii?Q?KXnJGuxloR4CXvprnvTgNBfAjtrg7QnhTg0kyvrm3RdFlx4ZnkSwApry7pW/?= =?us-ascii?Q?/0Apig3nFoV09EsfH+7jrNi+ozUt3EAulDBjnAKvllX7i2WSFN3+G/dmQRuB?= =?us-ascii?Q?sWG8x46xj9Ot9nmoh6LiHImV6BcLk+9qPoxRRWVlIBrNL8IwGi/fkcors/3y?= =?us-ascii?Q?Cl5zAJ6D1ZgDT0bm1UOHI2zISzZWgO6EdWFBsq+6MqZqRFBhWAmQWFIcWyzT?= =?us-ascii?Q?tpVwfVr0Qzzmbp62JKgJMWTHP7iIPI832yIJR6cHqCzwYsPJ9Lv4lFJX7af2?= =?us-ascii?Q?QvqnQFFehvYeTigfjqN8ZgcYCb/5QhBtcOWsq6adrYiOCWAEw/pGATzYkEbG?= =?us-ascii?Q?c7PorXZ7MUdTLJhxpgqR3wukw3EbLHRvEXehR46qkLem5lg0mepMCBPAykSV?= =?us-ascii?Q?oPhDziNfQsm5DF7Y0KDRvA4jwh77ZN1Qqc1o5UQNMHub44YmXZbyX0oaD14G?= =?us-ascii?Q?LXm6nOkswMPVBbbbKF4296liXEKpLuXk5pfEE+k9wc5edsVRxz/tENqqjUrz?= =?us-ascii?Q?hzqQtLihtEoiOlHtaAyhQ8dFpBUPqNWOJxJFeGJniyC7MubzOQpSTxMU/ljt?= =?us-ascii?Q?6afdjGgHY9yEyMqwybFinVrPZcNdJHHts0GHGiSR5HiFf3gzcyepjuXDFaxv?= =?us-ascii?Q?dD08jXDIUPW1pvbMuu0sCk/YWPGbdvEwvRgCGetuEITpuquIspBTMItjiT1t?= =?us-ascii?Q?Se2qCBclnaeTdA43h4T5N702SQhO6xrQoBDyiRXsgWNvgLMMp1PuUN2YzuuX?= =?us-ascii?Q?mDigBLbG63Psc6B609rRQe6XwJ6mtx9et3mg1Pdh5uujD8f16rpIwv+Jage2?= =?us-ascii?Q?808wurcmqr5EsXEJQqC70DDdmGGVOWXdnxIzpwTWjEQE94DuCsWZtPlCZMkJ?= =?us-ascii?Q?ymRlfr+IWDCIp3F0ugCwF62Vofr9nGapsrSl5Hhb18k55RZYsoKybimsVVbq?= =?us-ascii?Q?DtQ=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3548.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 73e20a46-a79f-4b97-91a6-08d8f69c7f52 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2021 12:32:08.2984 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /tS14zBMOdCibcj7P3dWIx+ON95aAhAY+zjhMSftUp2BmhNLpZMG82aKe4seKIlZssfo8bc85oLUgtRBtXxQ29cIFI0/76etLql5aOfUszk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3724 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v4 1/3] eventdev: introduce crypto adapter enqueue API 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 Sender: "dev" > -----Original Message----- > From: Shijith Thotton > Sent: Friday, April 2, 2021 10:31 PM > To: dev@dpdk.org > Cc: Akhil Goyal ; thomas@monjalon.net; > jerinj@marvell.com; Gujjar, Abhinandan S ; > hemant.agrawal@nxp.com; nipun.gupta@nxp.com; > sachin.saxena@oss.nxp.com; anoobj@marvell.com; matan@nvidia.com; > Zhang, Roy Fan ; g.singh@nxp.com; Carrillo, Erik > G ; Jayatheerthan, Jay > ; pbhagavatula@marvell.com; Van Haaren, > Harry ; Shijith Thotton > > Subject: [PATCH v4 1/3] eventdev: introduce crypto adapter enqueue API >=20 > From: Akhil Goyal >=20 > In case an event from a previous stage is required to be forwarded to a > crypto adapter and PMD supports internal event port in crypto adapter, > exposed via capability > RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD, we do not > have a way to check in the API rte_event_enqueue_burst(), whether it is f= or > crypto adapter or for eth tx adapter. I may be missing something here. Crypto adapter is an atomic stage has a po= rt which is setup during the adapter configuration. So, application enqueuing events will end up sending to the crypto adapter = (As the adapter dequeues from a specific port). Still wondering why there is requirement for new API. >=20 > Hence we need a new API similar to rte_event_eth_tx_adapter_enqueue(), > which can send to a crypto adapter. >=20 > Note that RTE_EVENT_TYPE_* cannot be used to make that decision, as it is > meant for event source and not event destination. > And event port designated for crypto adapter is designed to be used for > OP_NEW mode. >=20 > Hence, in order to support an event PMD which has an internal event port = in > crypto adapter (RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD mode), > exposed via capability > RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD, > application should use rte_event_crypto_adapter_enqueue() API to > enqueue events. >=20 > When internal port is not available(RTE_EVENT_CRYPTO_ADAPTER_OP_NEW > mode), application can use API rte_event_enqueue_burst() as it was doing > earlier, i.e. retrieve event port used by crypto adapter and bind its eve= nt > queues to that port and enqueue events using the API > rte_event_enqueue_burst(). >=20 > Signed-off-by: Akhil Goyal > --- > .../prog_guide/event_crypto_adapter.rst | 69 ++++++++++++------- > doc/guides/rel_notes/release_21_05.rst | 6 ++ > lib/librte_eventdev/eventdev_trace_points.c | 3 + > .../rte_event_crypto_adapter.h | 63 +++++++++++++++++ > lib/librte_eventdev/rte_eventdev.c | 10 +++ > lib/librte_eventdev/rte_eventdev.h | 8 ++- > lib/librte_eventdev/rte_eventdev_trace_fp.h | 10 +++ > lib/librte_eventdev/version.map | 3 + > 8 files changed, 145 insertions(+), 27 deletions(-) >=20 > diff --git a/doc/guides/prog_guide/event_crypto_adapter.rst > b/doc/guides/prog_guide/event_crypto_adapter.rst > index 1e3eb7139..4fb5c688e 100644 > --- a/doc/guides/prog_guide/event_crypto_adapter.rst > +++ b/doc/guides/prog_guide/event_crypto_adapter.rst > @@ -55,21 +55,22 @@ which is needed to enqueue an event after the > crypto operation is completed. > RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD mode > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >=20 > -In the RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD mode, if HW supports > -RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD capability > the application -can directly submit the crypto operations to the cryptod= ev. > -If not, application retrieves crypto adapter's event port using > -rte_event_crypto_adapter_event_port_get() API. Then, links its event - > queue to this port and starts enqueuing crypto operations as events -to t= he > eventdev. The adapter then dequeues the events and submits the -crypto > operations to the cryptodev. After the crypto completions, the -adapter > enqueues events to the event device. > -Application can use this mode, when ingress packet ordering is needed. > -In this mode, events dequeued from the adapter will be treated as - > forwarded events. The application needs to specify the cryptodev ID -and > queue pair ID (request information) needed to enqueue a crypto -operation > in addition to the event information (response information) -needed to > enqueue an event after the crypto operation has completed. > +In the ``RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD`` mode, if the event > PMD > +and crypto PMD supports internal event port > +(``RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD``), the > +application should use ``rte_event_crypto_adapter_enqueue()`` API to > +enqueue crypto operations as events to crypto adapter. If not, > +application retrieves crypto adapter's event port using > +``rte_event_crypto_adapter_event_port_get()`` API, links its event > +queue to this port and starts enqueuing crypto operations as events to > +eventdev using ``rte_event_enqueue_burst()``. The adapter then > dequeues > +the events and submits the crypto operations to the cryptodev. After > +the crypto operation is complete, the adapter enqueues events to the > +event device. The application can use this mode when ingress packet > +ordering is needed. In this mode, events dequeued from the adapter will > +be treated as forwarded events. The application needs to specify the > +cryptodev ID and queue pair ID (request information) needed to enqueue > +a crypto operation in addition to the event information (response > +information) needed to enqueue an event after the crypto operation has > +completed. >=20 > .. _figure_event_crypto_adapter_op_forward: >=20 > @@ -120,28 +121,44 @@ service function and needs to create an event port > for it. The callback is expected to fill the ``struct > rte_event_crypto_adapter_conf`` structure passed to it. >=20 > -For RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD mode, the event port > created by adapter -can be retrieved using > ``rte_event_crypto_adapter_event_port_get()`` API. > -Application can use this event port to link with event queue on which it= - > enqueues events towards the crypto adapter. > +In the ``RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD`` mode, if the event > PMD > +and crypto PMD supports internal event port > +(``RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD``), > events with > +crypto operations should be enqueued to the crypto adapter using > +``rte_event_crypto_adapter_enqueue()`` API. If not, the event port > +created by the adapter can be retrieved using > +``rte_event_crypto_adapter_event_port_get()`` > +API. An application can use this event port to link with an event > +queue, on which it enqueues events towards the crypto adapter using > +``rte_event_enqueue_burst()``. >=20 > .. code-block:: c >=20 > - uint8_t id, evdev, crypto_ev_port_id, app_qid; > + uint8_t id, evdev_id, cdev_id, crypto_ev_port_id, app_qid; > struct rte_event ev; > + uint32_t cap; > int ret; >=20 > - ret =3D rte_event_crypto_adapter_event_port_get(id, > &crypto_ev_port_id); > - ret =3D rte_event_queue_setup(evdev, app_qid, NULL); > - ret =3D rte_event_port_link(evdev, crypto_ev_port_id, &app_qid, = NULL, > 1); > - > // Fill in event info and update event_ptr with rte_crypto_op > memset(&ev, 0, sizeof(ev)); > - ev.queue_id =3D app_qid; > . > . > ev.event_ptr =3D op; > - ret =3D rte_event_enqueue_burst(evdev, app_ev_port_id, ev, > nb_events); > + > + ret =3D rte_event_crypto_adapter_caps_get(evdev_id, cdev_id, &ca= p); > + if (cap & > RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD) { > + ret =3D rte_event_crypto_adapter_enqueue(evdev_id, > app_ev_port_id, > + ev, nb_events); > + } else { > + ret =3D rte_event_crypto_adapter_event_port_get(id, > + &crypto_ev_port_= id); > + ret =3D rte_event_queue_setup(evdev_id, app_qid, NULL); > + ret =3D rte_event_port_link(evdev_id, crypto_ev_port_id,= &app_qid, > + NULL, 1); > + ev.queue_id =3D app_qid; > + ret =3D rte_event_enqueue_burst(evdev_id, app_ev_port_id= , ev, > + nb_events); > + } > + >=20 > Querying adapter capabilities > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > diff --git a/doc/guides/rel_notes/release_21_05.rst > b/doc/guides/rel_notes/release_21_05.rst > index e2b0886a9..0bee94877 100644 > --- a/doc/guides/rel_notes/release_21_05.rst > +++ b/doc/guides/rel_notes/release_21_05.rst > @@ -106,6 +106,12 @@ New Features > * Added support for periodic timer mode in eventdev timer adapter. > * Added support for periodic timer mode in octeontx2 event device driv= er. >=20 > +* **Enhanced crypto adapter forward mode.** > + > + * Added ``rte_event_crypto_adapter_enqueue()`` API to enqueue events > to crypto > + adapter if forward mode is supported by driver. > + * Added support for crypto adapter forward mode in octeontx2 event and > crypto > + device driver. >=20 > Removed Items > ------------- > diff --git a/lib/librte_eventdev/eventdev_trace_points.c > b/lib/librte_eventdev/eventdev_trace_points.c > index 1a0ccc448..3867ec800 100644 > --- a/lib/librte_eventdev/eventdev_trace_points.c > +++ b/lib/librte_eventdev/eventdev_trace_points.c > @@ -118,3 +118,6 @@ > RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_crypto_adapter_start, >=20 > RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_crypto_adapter_stop, > lib.eventdev.crypto.stop) > + > +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_crypto_adapter_enque > ue, > + lib.eventdev.crypto.enq) > diff --git a/lib/librte_eventdev/rte_event_crypto_adapter.h > b/lib/librte_eventdev/rte_event_crypto_adapter.h > index 60630ef66..a4a4129b7 100644 > --- a/lib/librte_eventdev/rte_event_crypto_adapter.h > +++ b/lib/librte_eventdev/rte_event_crypto_adapter.h > @@ -171,6 +171,7 @@ extern "C" { > #include >=20 > #include "rte_eventdev.h" > +#include "eventdev_pmd.h" >=20 > /** > * Crypto event adapter mode > @@ -522,6 +523,68 @@ rte_event_crypto_adapter_service_id_get(uint8_t > id, uint32_t *service_id); int > rte_event_crypto_adapter_event_port_get(uint8_t id, uint8_t > *event_port_id); >=20 > +/** > + * Enqueue a burst of crypto operations as events object supplied in events object -> event objects > +*rte_event* > + * structure on an event crypto adapter designated by its event > +*dev_id* through > + * the event port specified by *port_id*. This function is supported if > +the > + * eventdev PMD has the > +#RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD > + * capability flag set. > + * > + * The *nb_events* parameter is the number of event objects to enqueue > +which are > + * supplied in the *ev* array of *rte_event* structure. > + * > + * The rte_event_crypto_adapter_enqueue() function returns the number > +of > + * events objects it actually enqueued. A return value equal to events object -> event objects > +*nb_events* > + * means that all event objects have been enqueued. > + * > + * @param dev_id > + * The identifier of the device. > + * @param port_id > + * The identifier of the event port. > + * @param ev > + * Points to an array of *nb_events* objects of type *rte_event* > +structure > + * which contain the event object enqueue operations to be processed. > + * @param nb_events > + * The number of event objects to enqueue, typically number of > + * rte_event_port_attr_get(...RTE_EVENT_PORT_ATTR_ENQ_DEPTH...) > + * available for this port. > + * > + * @return > + * The number of event objects actually enqueued on the event device. > The > + * return value can be less than the value of the *nb_events* paramete= r > when > + * the event devices queue is full or if invalid parameters are specif= ied in a > + * *rte_event*. If the return value is less than *nb_events*, the rema= ining > + * events at the end of ev[] are not consumed and the caller has to ta= ke > care > + * of them, and rte_errno is set accordingly. Possible errno values in= clude: > + * - EINVAL The port ID is invalid, device ID is invalid, an event's= queue > + * ID is invalid, or an event's sched type doesn't match th= e > + * capabilities of the destination queue. > + * - ENOSPC The event port was backpressured and unable to enqueue > + * one or more events. This error code is only applicable t= o > + * closed systems. > + */ > +static inline uint16_t > +rte_event_crypto_adapter_enqueue(uint8_t dev_id, > + uint8_t port_id, > + struct rte_event ev[], > + uint16_t nb_events) > +{ > + const struct rte_eventdev *dev =3D &rte_eventdevs[dev_id]; > + > +#ifdef RTE_LIBRTE_EVENTDEV_DEBUG > + RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL); > + > + if (port_id >=3D dev->data->nb_ports) { > + rte_errno =3D EINVAL; > + return 0; > + } > +#endif > + rte_eventdev_trace_crypto_adapter_enqueue(dev_id, port_id, ev, > + nb_events); > + > + return dev->ca_enqueue(dev->data->ports[port_id], ev, > nb_events); } > + > #ifdef __cplusplus > } > #endif > diff --git a/lib/librte_eventdev/rte_eventdev.c > b/lib/librte_eventdev/rte_eventdev.c > index b57363f80..5674bd38e 100644 > --- a/lib/librte_eventdev/rte_eventdev.c > +++ b/lib/librte_eventdev/rte_eventdev.c > @@ -1405,6 +1405,15 @@ rte_event_tx_adapter_enqueue(__rte_unused > void *port, > return 0; > } >=20 > +static uint16_t > +rte_event_crypto_adapter_enqueue(__rte_unused void *port, > + __rte_unused struct rte_event ev[], > + __rte_unused uint16_t nb_events) Args are not aligned > +{ > + rte_errno =3D ENOTSUP; > + return 0; > +} > + > struct rte_eventdev * > rte_event_pmd_allocate(const char *name, int socket_id) { @@ -1427,6 > +1436,7 @@ rte_event_pmd_allocate(const char *name, int socket_id) >=20 > eventdev->txa_enqueue =3D rte_event_tx_adapter_enqueue; > eventdev->txa_enqueue_same_dest =3D > rte_event_tx_adapter_enqueue; > + eventdev->ca_enqueue =3D rte_event_crypto_adapter_enqueue; >=20 > if (eventdev->data =3D=3D NULL) { > struct rte_eventdev_data *eventdev_data =3D NULL; diff --git > a/lib/librte_eventdev/rte_eventdev.h > b/lib/librte_eventdev/rte_eventdev.h > index 9fc39e9ca..b50027f88 100644 > --- a/lib/librte_eventdev/rte_eventdev.h > +++ b/lib/librte_eventdev/rte_eventdev.h > @@ -1276,6 +1276,10 @@ typedef uint16_t > (*event_tx_adapter_enqueue_same_dest)(void *port, > * burst having same destination Ethernet port & Tx queue. > */ >=20 > +typedef uint16_t (*event_crypto_adapter_enqueue)(void *port, > + struct rte_event ev[], uint16_t nb_events); > /**< @internal Enqueue > +burst of events on crypto adapter */ > + > #define RTE_EVENTDEV_NAME_MAX_LEN (64) > /**< @internal Max length of name of event PMD */ >=20 > @@ -1347,6 +1351,8 @@ struct rte_eventdev { > */ > event_tx_adapter_enqueue txa_enqueue; > /**< Pointer to PMD eth Tx adapter enqueue function. */ > + event_crypto_adapter_enqueue ca_enqueue; > + /**< Pointer to PMD crypto adapter enqueue function. */ > struct rte_eventdev_data *data; > /**< Pointer to device data */ > struct rte_eventdev_ops *dev_ops; > @@ -1359,7 +1365,7 @@ struct rte_eventdev { > /**< Flag indicating the device is attached */ >=20 > uint64_t reserved_64s[4]; /**< Reserved for future fields */ > - void *reserved_ptrs[4]; /**< Reserved for future fields */ > + void *reserved_ptrs[3]; /**< Reserved for future fields */ > } __rte_cache_aligned; >=20 > extern struct rte_eventdev *rte_eventdevs; diff --git > a/lib/librte_eventdev/rte_eventdev_trace_fp.h > b/lib/librte_eventdev/rte_eventdev_trace_fp.h > index 349129c0f..5639e0b83 100644 > --- a/lib/librte_eventdev/rte_eventdev_trace_fp.h > +++ b/lib/librte_eventdev/rte_eventdev_trace_fp.h > @@ -49,6 +49,16 @@ RTE_TRACE_POINT_FP( > rte_trace_point_emit_u8(flags); > ) >=20 > +RTE_TRACE_POINT_FP( > + rte_eventdev_trace_crypto_adapter_enqueue, > + RTE_TRACE_POINT_ARGS(uint8_t dev_id, uint8_t port_id, void > *ev_table, > + uint16_t nb_events), > + rte_trace_point_emit_u8(dev_id); > + rte_trace_point_emit_u8(port_id); > + rte_trace_point_emit_ptr(ev_table); > + rte_trace_point_emit_u16(nb_events); > +) > + > RTE_TRACE_POINT_FP( > rte_eventdev_trace_timer_arm_burst, > RTE_TRACE_POINT_ARGS(const void *adapter, void **evtims_table, > diff --git a/lib/librte_eventdev/version.map > b/lib/librte_eventdev/version.map index 3e5c09cfd..c63ba7a9c 100644 > --- a/lib/librte_eventdev/version.map > +++ b/lib/librte_eventdev/version.map > @@ -138,6 +138,9 @@ EXPERIMENTAL { > __rte_eventdev_trace_port_setup; > # added in 20.11 > rte_event_pmd_pci_probe_named; > + > + # added in 21.05 > + __rte_eventdev_trace_crypto_adapter_enqueue; > }; >=20 > INTERNAL { > -- > 2.25.1