-----Original Message----- > Date: Sun, 6 May 2018 00:17:06 +0530 > From: Abhinandan Gujjar <abhinandan.guj...@intel.com> > To: jerin.ja...@caviumnetworks.com, hemant.agra...@nxp.com, > akhil.go...@nxp.com, dev@dpdk.org > CC: narender.vang...@intel.com, abhinandan.guj...@intel.com, > nikhil....@intel.com, gage.e...@intel.com > Subject: [v3,1/5] eventdev: introduce event crypto adapter > X-Mailer: git-send-email 1.9.1 > > Signed-off-by: Abhinandan Gujjar <abhinandan.guj...@intel.com> > Signed-off-by: Nikhil Rao <nikhil....@intel.com> > Signed-off-by: Gage Eads <gage.e...@intel.com> > --- > MAINTAINERS | 5 + > lib/librte_eventdev/rte_event_crypto_adapter.h | 554 > +++++++++++++++++++++++++ > 2 files changed, 559 insertions(+) > create mode 100644 lib/librte_eventdev/rte_event_crypto_adapter.h >
Overall it looks good. #1) Please fix the following ./devtools/checkpatches.sh warning. ➜ [master]laptop [dpdk.org] $ ./devtools/checkpatches.sh ### eventdev: add crypto adapter implementation WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #106: FILE: lib/librte_eventdev/rte_event_crypto_adapter.c:1: +/* SPDX-License-Identifier: BSD-3-Clause ### test: add event crypto adapter auto-test WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #38: FILE: test/test/test_event_crypto_adapter.c:1: +/* SPDX-License-Identifier: BSD-3-Clause total: 0 errors, 1 warnings, 927 lines checked ### doc: add event crypto adapter documentation WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #41: FILE: doc/guides/prog_guide/event_crypto_adapter.rst:1: +.. SPDX-License-Identifier: BSD-3-Clause * 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 cryptodev. * If not, #2) I have added minor changes in description, Wherever it makes sense to you then please pull it for next revision. Else we can discuss more. a) I have uploaded the diff at https://ufile.io/247t9 for you convince. b) Please update the similar change in programmers guide too. diff --git a/lib/librte_eventdev/rte_event_crypto_adapter.h b/lib/librte_eventdev/rte_event_crypto_adapter.h index 2c1f54f76..55fbdc55e 100644 --- a/lib/librte_eventdev/rte_event_crypto_adapter.h +++ b/lib/librte_eventdev/rte_event_crypto_adapter.h @@ -23,14 +23,17 @@ * between the crypto device and the event device. * * The application can choose to submit a crypto operation directly to - * crypto device or send it to the crypto adapter via eventdev, the crypto - * adapter then submits the crypto operation to the crypto device. - * The first mode is known as the event new (OP_NEW) mode and the - * second as the event forward (OP_FORWARD) mode. The choice of mode can - * be specified while creating the adapter. + * crypto device or send it to the crypto adapter via eventdev based on + * RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD capability. + * The first mode is known as the event new(RTE_EVENT_CRYPTO_ADAPTER_OP_NEW) + * mode and the second as the event forward(RTE_EVENT_CRYPTO_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 OP_NEW mode: + * Working model of RTE_EVENT_CRYPTO_ADAPTER_OP_NEW mode: * * +--------------+ +--------------+ * --[1]-->| | | Crypto stage | @@ -47,25 +50,27 @@ * | | | | * +--------------+ +--------------+ * - * [1] Events from the previous stage. + * [1] Events from the previous stage and enqueue to crypto/atomic stage * [2] Application in atomic stage dequeues events from eventdev. - * [3] Crypto operations are submitted to cryptodev. + * [3] Crypto operations are submitted to cryptodev by application. * [4] Crypto adapter dequeues crypto completions from cryptodev. * [5] Crypto adapter enqueues events to the eventdev. * [6] Events to the next stage. * - * In the OP_NEW mode, application submits crypto operations directly to - * crypto device. The adapter then dequeues crypto completions from crypto + * In the RTE_EVENT_CRYPTO_ADAPTER_OP_NEW mode, application submits crypto + * operations directly to crypto device. + * The adapter then dequeues crypto completions from crypto * device and enqueue events to the event device. - * This mode does not ensure ingress ordering. The application is expected - * to be in atomic stage. Events dequeued from the adapter will be treated - * as new events. + * This mode does not ensure ingress ordering if the application directly + * enqueues to cryptodev without going through crypto/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 crypto operation * is completed. * * - * Working model of OP_FORWARD mode: + * Working model of RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD mode: * * +--------------+ +--------------+ * --[1]-->| |---[2]-->| | @@ -93,8 +98,9 @@ * [7] Crypto adapter enqueues events to the eventdev * [8] Events to the next stage * - * In the OP_FORWARD mode, if HW supports *_OP_FORWARD capability the - * application can directly submit the crypto operations to the cryptodev. + * 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 cryptodev. * 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 @@ -121,7 +127,7 @@ * - rte_event_crypto_adapter_stop() * - rte_event_crypto_adapter_stats_get() * - rte_event_crypto_adapter_stats_reset() - + * * The application creates an instance using rte_event_crypto_adapter_create() * or rte_event_crypto_adapter_create_ext(). * @@ -173,8 +179,10 @@ enum rte_event_crypto_adapter_mode { /**< Start the crypto adapter in event forward mode. * @see RTE_EVENT_OP_FORWARD. * Application submits crypto requests as events to the crypto - * adapter. Adapter submits crypto requests to the cryptodev - * and crypto completions are enqueued back to the eventdev. + * adapter or crypto device based on + * RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD capability. + * crypto completions are enqueued back to the eventdev by + * crypto adapter. */ }; @@ -215,11 +223,12 @@ struct rte_event_crypto_request { union rte_event_crypto_metadata { struct rte_event_crypto_request request_info; /**< Request information to be filled in by application - * for OP_FORWARD mode. + * for RTE_EVENT_CRYPTO_ADAPTER_OP_NEW mode. */ struct rte_event response_info; /**< Response information to be filled in by application - * for OP_NEW and OP_FORWARD mode. + * for RTE_EVENT_CRYPTO_ADAPTER_OP_NEW and + * RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD mode. */ }; @@ -234,7 +243,8 @@ union rte_event_crypto_metadata { struct rte_event_crypto_adapter_conf { uint8_t event_port_id; /**< Event port identifier, the adapter enqueues events to this - * port and dequeues crypto request events in OP_FORWARD mode. + * port and dequeues crypto request events in + * RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD mode. */ uint32_t max_nb; /**< The adapter can return early if it has processed at least
