From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0084.outbound.protection.outlook.com [104.47.32.84]) by dpdk.org (Postfix) with ESMTP id 8D57D1B1B0 for ; Fri, 16 Feb 2018 20:34:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZT+nWUd8ztIaT0I5XQ5jpOolmWHxdftaq2NLo1NThrY=; b=JKjmg4oBabRtrmXo1AVn6glqMD4SwjyQaO3QGCpkeo272fWR8rV5r8yG/hPhyeaBk6JTekvM2jk3L1NdfqyxaEw245jtZvVmYZYoc9LmeKbYzKYJSfzMqnGQnbXBCAK3UuwT32NpshBxEwVhTXMvRi3baB+M3ePvdnpyhfXSpmQ= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; Received: from jerin (171.76.101.225) by BN3PR07MB2514.namprd07.prod.outlook.com (2a01:111:e400:7bbf::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Fri, 16 Feb 2018 19:34:01 +0000 Date: Sat, 17 Feb 2018 01:03:49 +0530 From: Jerin Jacob To: Abhinandan Gujjar Cc: dev@dpdk.org, narender.vangati@intel.com, Nikhil Rao , Gage Eads , hemant.agrawal@nxp.com, akhil.goyal@nxp.com, narayanaprasad.athreya@cavium.com, nidadavolu.murthy@cavium.com, nithin.dabilpuram@cavium.com Message-ID: <20180216193348.GA8882@jerin> References: <1516013630-146114-1-git-send-email-abhinandan.gujjar@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1516013630-146114-1-git-send-email-abhinandan.gujjar@intel.com> User-Agent: Mutt/1.9.3 (2018-01-21) X-Originating-IP: [171.76.101.225] X-ClientProxiedBy: BM1PR0101CA0001.INDPRD01.PROD.OUTLOOK.COM (2603:1096:b00:18::11) To BN3PR07MB2514.namprd07.prod.outlook.com (2a01:111:e400:7bbf::11) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1ac2b51d-9896-4d5c-c6a6-08d575743d39 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:BN3PR07MB2514; X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2514; 3:7oOulFFcGSSGKsQPx0vqVup0ut94JDSgrdG4SUzwdtI7or82rC/Chs3uHIPi30nBBlwrL4lv1iy6PJL+Zj548q51viMTrAv2JDT4pijJHLSoX1gtonUkxhRY8lDjwnrqwc0sZTwXG6z2cFIuz2opPIq0iHyr4GBuRG6fxhxG2F9qgQ0Gx219yeJ173t8g+HIf0Fdo4PeBbMpeBqW6Lt3o3ee2gyU874iKU/e8hPgwRfcWV+ofYCxP/tzGZQ/8r5X; 25:vlGs4H76By52e9kvU2mt4nd70nbACbftrMnvdnL/XDQlNx0lEzy86B94aEY1O36rFMETBoEJrJTrRweEXJw/wlmSnnyEdxqUbHyM8QU98a1276bYdj1g49ll3PMOAq+JawuysiMfZawgEpN2LcE5ykq1dujlZcBjSah7S+skd2+19Q1TiUAX3c2/cpeimt+Vv/jovufa4FRJbYERDsIx6tgu8r1Mm+ySDWqJiVvg6IxlfuZVpmVJwv+DEzODCQq6R6HNFh8N27Kn8434+eQhnkpWYFfIJCN11xfpiJn1zdnFd9VI9UlPGyxsjHWg+w3jITR820R1MiKp+ldW790PEg==; 31:sjXmeXFtgc3WMDbmFeGB4xD+0zeqTjB65pFDnmeqdO7yUglKZ+hA3uhim+4x6K4nmBSEPJcRFrym/NyJO22vygIpVtIi05iVHnm9/kCHzVP7VTtnBsupdCJBy8uIBavzCT5+bKNMEQAinyMbj+NBbblOwwtycVQZ+FGyonjbY5mctbghkRPD09Dh0NipMetGMbNtxJyQeeESO89E8WGFIir1osGDPj70EML8zhTEGIM= X-MS-TrafficTypeDiagnostic: BN3PR07MB2514: X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2514; 20:cOPdno1Z7frPPLHKMuoGRGsR7NuRhspg2Ec418fxLyYHsRXtNBsN7jV3fgFn40gfI8DqVbd4zLFcVkfKnJQBjHwjKGeoGdbFjrlfJgt4b/K96wU3NX+cWFIE8kp9dQHxvQ9M51l6ZJH+dWD9kr1e48N+C3nXlI6R70lubwD7i/eNjaAXQOpWbupA29foSt0WPSSTO/WRv33GUzBRVVCgzqqFUdNyu71v/6YSJvC6yFYTcAtMxHQTqJ0cQ9kfbPEvuccw/YK5fm/ya+U3ljHtgOFlQZn2P1dd2TtMu0x+Kn9kx9sCHdxN9Y80oxmPvkEeLpZXwRT0IRjIWPg1coagk6s1VaJ8sLJ2Jg57wSWzw5esDsgzpu5jHBiKs+Imm5ev4KsFXtmujDOBJDLPmuC/Fv6HPNqVdDyh/4ErI7pIq+enX13r3UBxwlf9xpbD2IXyOjkZaObUkhvYS/nX+VeneteP9byFMeDP+svuNgler+v2xAG9RUj7SpWK5dMZCeSPNzkm/hDtItG0Huc3MWOrRkNxiwMdyhLuhzTUIjqZArasvfxgoOys4GkXfv1vEXjTm26j6DRzJfeE4Tthdq0DfJmKrOV8DNCjp1y/SnFABoA= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001037)(6040501)(2401047)(8121501046)(5005006)(10201501046)(3231101)(944501161)(3002001)(93006095)(6041288)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:BN3PR07MB2514; BCL:0; PCL:0; RULEID:; SRVR:BN3PR07MB2514; X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2514; 4:yS/tjW1mMwE1424T4Z2hm1d3BjlLthVbDAZIKo3nlNEIZsMOnLMkdlxSvGTRatFumj1miLKg84ylSQ0g+oZmOiFpEsgr+tv9f7S+M+E9QxLBEv9XZ7PWfRT8Px+EfN15O9Dm3dZ1deOxqQm2wOxEf1iX0AMX98UGOL939JeINryGqzV6fGUXFyS+v4U2T0CwloyXGJr9VFbvP4UKbym7UtW7BlaHIGEEIeSEbukJK2uxcWClH5V3A55eCqLszzcY2K5ZxiysXBPjtJYgjMhzAMWL0O0+DHmC+51GDTFjbe/Fe2XzbnrEFvGf7sj5393xBG5xu0yvcCIwI7HHAyrn/VMzKQ2iJdWI0qCXXU5gxG0= X-Forefront-PRVS: 0585417D7B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39850400004)(396003)(346002)(39380400002)(199004)(189003)(13464003)(7736002)(16586007)(5660300001)(33716001)(105586002)(478600001)(8676002)(54906003)(81156014)(72206003)(97736004)(81166006)(26005)(386003)(50466002)(186003)(16526019)(106356001)(33896004)(59450400001)(305945005)(8936002)(1076002)(66066001)(107886003)(229853002)(3846002)(6116002)(83506002)(25786009)(6246003)(58126008)(4326008)(33656002)(6666003)(23726003)(55016002)(68736007)(316002)(6496006)(53936002)(8656006)(9686003)(2950100002)(42882006)(6916009)(2906002)(52116002)(76176011)(47776003)(18370500001)(21314002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR07MB2514; H:jerin; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR07MB2514; 23:FBUxDfl83ZLh4zFQx14kMiXGZmVxCHqFhxMV+TSlt?= =?us-ascii?Q?8ujmxUrMRowdytAbillSbIDClF4NTJglfI1fA5qKOeK8aAgnjVrBvBf7YV4q?= =?us-ascii?Q?nGFCDYFCIRw2d/dNqhkWjz0D21iAp6qk/nxOVKfAcjWknOxcA/WpkaeBfcDS?= =?us-ascii?Q?D2/vt86bEDMm21MsoKEPKuhqIOohGd/wlMt5SA2IPRC8ml8uRwmbMhcP/4PP?= =?us-ascii?Q?J0VVTXfWFjFG0zW54rLvadheRcURHzknzUDvjUCx11QDWmsvDRSXqab6ggf5?= =?us-ascii?Q?f85B85MiLZWRmKgnA960+UxLpnIx1uSLoGOzZ0pqtfPRESkFBGz0lCQ+PWnT?= =?us-ascii?Q?KrzV5eDSZoEukbMtkovA8Mhi/pgmiYeqdZ/QbAsVQEVuPAJ3S/g0fD3qCIgf?= =?us-ascii?Q?XXEsIdQ3+twDlnnNkE8DWKo8brw+p9tK45jmxo+6giaG08JQBVlFis901Sqa?= =?us-ascii?Q?QajvvT4DZzUVmOmKRAITNigoukfM0MamJTLoFaj21F+lVRLD6FFoKQa136pP?= =?us-ascii?Q?2wVqGZBIFFw+P4DzpgSzFBeGl1H8rJEcV35ElNWvzodD83Vry8N2oIED6rbC?= =?us-ascii?Q?t+9glan/jn+lS54yGUh1PifWdVydAnLXX1sTsNu6anHaY/XPile8bk7f+pLL?= =?us-ascii?Q?xwgzws49mhaCvWLDw/f7ii75FjOh7jq8Z0fED8ehMmNlScZtE0sS6+I+IqaG?= =?us-ascii?Q?w95qf37U4gkCj/zf2W2hMYSai/yQa3kveR40+Wk51DycZbzvEg8Z/x1Yktga?= =?us-ascii?Q?mZwUgAAz2lmSGlzefjtfIEnUApWnIEb9eW8jjhwMxB7nYJ/ovwmUzZgv6H2L?= =?us-ascii?Q?C8o5MA8YWg7yX66ewYFEK9BcrdIchrEOWdXSFEGTvHjxynWv0Syl+lz8nLjr?= =?us-ascii?Q?f5g5ysIcNGlhlfLFltGdJmz5WDOdJGp8ZRYqrFFWg2oMypoXSM33Q8Sey1q4?= =?us-ascii?Q?1mGeLWl5sdBYHxdnG/INaSeN055Jty7IrDnfolBUx9WAI9kMOB6hUmnA+cgJ?= =?us-ascii?Q?T9qYP9s63ig7oIXfU0As04YZvY7FT7nXkXGgEG+F7znYKgm/Y7cmZRs25IlU?= =?us-ascii?Q?pzDvfdIJsu5dduserN0kLODczXmf9IbJLzQbi24cnF+FaU0bxEW1N/Oji5v0?= =?us-ascii?Q?PPIro5294vGIJmRqUOm8hDjqA798vXdhu9bXAyfObdsSxnTVG/mxAqWttthW?= =?us-ascii?Q?eVhOb86yZdpjkTH2GP6kXbGLznspTJnx7eXND1JBO+vA6yr7R79ujc3pDWVc?= =?us-ascii?Q?k8z99rs+xSt70GGybT/tWR03SpzLTbb4BPCk+mIzFMEN+JGKBC/ejO1nQ5IG?= =?us-ascii?Q?HQQ7cgwYUt1SHO0MRfRAENcscqOWX0077ayCdycvpYgGz6DWLVMWXKauyBBo?= =?us-ascii?Q?YfKvd/fN3sFwVvnEhJD+0EDeHI=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2514; 6:029+pzS+REOUfUn4Zm2P2Q/gUBNdAadwNjzJO+At4H200+S1AayRaF6f2RV570ken6qFmjS5V19YpAHlBvDp49mIKV5+arAaAgkX+s0zmw+EcdgtJ9rlSecWB8Ad9zcdS4Q72zVbR9NcdZwi15Vgpv4+FW/9/R6DRAdG611ZRy1oD5FV/u0tnzxI9CE5e1PIZVrMqJRgwOKDWGvzdYBVqo96qw1iGGl5TUMUHGZetcP4vEWoj8qDb1DUq6o9BLO0hxdOGijv67dH80vzJtnguvCoux+zciXjL40zKlol/FoPcyfbLjWJO1bcyFcCzLMtmLEsENodkH4rx2e82ammzn2BaQbssXyfwK8RIlkikiA=; 5:sbXGDawLRuWwnKuhB/E3okSkOh36Sy2nN5Wdk2i+sO1LbqgGF68Ifq4UgoP+mVOsd5LW+WafeqjcapjsO6dgNut/oKyEqyc+O9AtFoXlxrRsG6uDifIri7PTjwJ19l0PgrGvTzkAQK/Zj84iNgosYkjc/GpWf04UVvCju9fUK2w=; 24:F3wKIqh9cbgKJsM+Ao7JgiVJPbPxkmCOzXxgyAklz7FNYV2f2kQDMIu5+Sc2EfEH3Aeum6Ts+CDQ8wsNxHQenZAcahoIo9UiGePuh+pn4Qw=; 7:dX4SNzKTTIvZHN0zGYTUjnr1ScxPaduGT6xSRpdgbUwLiXsfndhDSXDp8ntvEKcm66Ayc1PSuojSFbemN0KE3vs+tXftEkdzge6W70HgYWtOlF6vqbmfe2Q9JUHIpe9deVB4j3QMHL5lbtQWHnU+mWip9JDl6Og+tyq2TmxIVy5kkKfhHSTUKZhMq/WTGVjInGZZaqw1YmRDCGyvE0t6mAaCDa6tkXkDBOduxF1ryiqrfVsFYB+Pz68b0AIb57PL SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2018 19:34:01.9764 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1ac2b51d-9896-4d5c-c6a6-08d575743d39 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR07MB2514 Subject: Re: [dpdk-dev] [RFC v2, 2/2] eventdev: add crypto adapter API header X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 19:34:08 -0000 -----Original Message----- > Date: Mon, 15 Jan 2018 16:23:50 +0530 > From: Abhinandan Gujjar > To: jerin.jacob@caviumnetworks.com > CC: dev@dpdk.org, narender.vangati@intel.com, Abhinandan Gujjar > , Nikhil Rao , Gage > Eads > Subject: [RFC v2, 2/2] eventdev: add crypto adapter API header > X-Mailer: git-send-email 1.9.1 > > Add crypto event adapter APIs to support packet transfer > mechanism between cryptodev and event device. > > Signed-off-by: Abhinandan Gujjar > Signed-off-by: Nikhil Rao > Signed-off-by: Gage Eads > --- Overall it looks good to me. Though I have some confusion over ENQ-DEQ scheme. May be it will be get cleared along with implementation. > Notes: > V2: > 1. Updated type as ENQ-DEQ in rte_event_crypto_adapter_type > 2. Removed enum rte_event_crypto_conf_type > 3. Updated struct rte_event_crypto_metadata > 4. Removed struct rte_event_crypto_queue_pair_conf > 5. Updated rte_event_crypto_adapter_queue_pair_add() API > > lib/librte_eventdev/Makefile | 1 + > lib/librte_eventdev/rte_event_crypto_adapter.h | 452 +++++++++++++++++++++++++ 1) Please update MAINTAINERS file 2) Add meson build support 3) Update doc/api/doxy-api-index.md file and check the doxygen output using "make doc-api-html" 4) Please add the programmers guide in doc/guides/prog_guide/ > > +++ b/lib/librte_eventdev/rte_event_crypto_adapter.h > @@ -0,0 +1,452 @@ > +/* > + * Copyright(c) 2018 Intel Corporation. All rights reserved. > + * All rights reserved. > + * > + * Redistribution and use in source and binary forms, with or without Use SPDX tag scheme > +#ifndef _RTE_EVENT_CRYPTO_ADAPTER_ > +#define _RTE_EVENT_CRYPTO_ADAPTER_ > + > +/** > + * This adapter adds support to enqueue crypto completions to event device. > + * The packet flow from cryptodev to the event device can be accomplished > + * using both SW and HW based transfer mechanisms. > + * The adapter uses a EAL service core function for SW based packet transfer > + * and uses the eventdev PMD functions to configure HW based packet transfer > + * between the cryptodev and the event device. > + * > + * In the case of SW based transfers, application can choose to submit a I think, we can remove "In the case of SW based transfers" as it should be applicable for HW case too > + * crypto operation directly to cryptodev or send it to the cryptodev > + * adapter via eventdev, the cryptodev adapter then submits the crypto > + * operation to the crypto device. The first mode is known as the The first mode (DEQ) is very clear. In the second mode(ENQ_DEQ), - How does "worker" submits the crypto work through crypto-adapter? If I understand it correctly, "workers" always deals with only cryptodev's rte_cryptodev_enqueue_burst() API and "service" function in crypto adapter would be responsible for dequeue() from cryptodev and enqueue to eventdev? I understand the need for OP_NEW vs OP_FWD mode difference in both modes. Other than that, What makes ENQ_DEQ different? Could you share the flow for ENQ_DEQ mode with APIs. > + * dequeue only (DEQ) mode and the second as the enqueue - dequeue extra space between "mode" and "and" > + * (ENQ_DEQ) mode. The choice of mode can be specified when creating > + * the adapter. > + * In the latter choice, the cryptodev adapter is able to use > + * RTE_OP_FORWARD as the event dev enqueue type, this has a performance > + * advantage in "closed system" eventdevs like the eventdev SW PMD and s/eventdevs/eventdev ?? > + * also, the event cannot be dropped. > + * > + * In the ENQ_DEQ mode the application needs to specify the cryptodev ID > + * and queue pair ID (request information) in addition to the event > + * information (response information) needed to enqueue an event after > + * the crypto operation has completed. The request and response information > + * are specified in the rte_crypto_op private_data. In the DEQ mode the > + * the application is required to provide only the response information. Why ENQ_DEQ modes needs cryptodev ID and queue pair ID? Which is part of rte_cryptodev_enqueue_burst(). May be I am missing something. If ENQ_DEQ modes help in SW case then we can add it as capability. I am just trying to see any scope of convergence. > + * > + * In the ENQ_DEQ mode, application sends crypto operations as events to > + * the adapter which dequeues events and programs cryptodev operations. > + * The adapter then dequeues crypto completions from cryptodev and > + * enqueue events to the event device. > + * > + * In the case of HW based transfers, the cryptodev PMD callback invoked > + * from rte_cryptodev_enqueue_burst() uses the response information to > + * setup the event for the cryptodev completion. > + * > + * The event crypto adapter provides common APIs to configure the packet flow > + * from the cryptodev to event devices across both SW and HW based transfers. > + * The crypto event adapter's functions are: > + * - rte_event_crypto_adapter_create_ext() > + * - rte_event_crypto_adapter_create() > + * - rte_event_crypto_adapter_free() > + * - rte_event_crypto_adapter_queue_pair_add() > + * - rte_event_crypto_adapter_queue_pair_del() > + * - rte_event_crypto_adapter_start() > + * - rte_event_crypto_adapter_stop() > + * - rte_event_crypto_adapter_stats_get() > + * - rte_event_crypto_adapter_stats_reset() > + > + * The applicaton creates an instance using rte_event_crypto_adapter_create() s/applicaton/application > + * or rte_event_crypto_adapter_create_ext(). > + * > + * Cryptodev queue pair addition/deletion is done > + * using the rte_event_crypto_adapter_queue_pair_xxx() APIs. > + * > + * The SW adapter or HW PMD uses rte_crypto_op::private_data_type to decide > + * whether request/response data is located in the crypto session/crypto > + * security session or at an offset in the rte_crypto_op. > + * rte_crypto_op::private_data_offset is used to locate the request/response > + * in the rte_crypto_op. If the rte_crypto_op::private_data_type > + * indicates that the data is in the crypto session/crypto security session > + * then the rte_crypto_op::sess_type is used to decide whether the private > + * data is in the session or security session. > + * > + * For session-less it is mandatory to place the request/response data with > + * the rte_crypto_op where as with crypto session/security session it can be > + * placed with the rte_crypto_op or in the session/security session. Please update(if needed) above two paragraphs based on the conclusion from cryptodev change > + */ > + > +#ifdef __cplusplus > +extern "C" { > +#endif > + > +#include > +#include > + > +#include "rte_eventdev.h" > + > +#define RTE_EVENT_CRYPTO_ADAPTER_MAX_INSTANCE 32 > + > +/** > + * @warning > + * @b EXPERIMENTAL: this enum may change without prior notice Change to new EXPERIMENTAL tag scheme. > + * > + * Crypto event adapter type > + */ > +enum rte_event_crypto_adapter_type { > + RTE_EVENT_CRYPTO_ADAPTER_DEQ_ONLY = 1, > + /**< Start only dequeue part of crypto adapter. > + * Packets dequeued from cryptodev are enqueued to eventdev > + * as new events and events will be treated as RTE_EVENT_OP_NEW. */ > + RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ, > + /**< Start both enqueue & dequeue part of crypto adapter. > + * Packet's event context will be retained and > + * event will be treated as RTE_EVENT_OP_FORWARD. */ This description makes sense. > +}; > + > +/** > + * @warning > + * @b EXPERIMENTAL: this structure may change without prior notice > + * > + * Crypto event request structure will be fill by application to > + * provide event request information to the adapter. > + */ > +struct rte_event_crypto_request { > + uint8_t resv[8]; > + /**< Overlaps with first 8 bytes of struct rte_event > + * that encode the response event information > + */ > + uint16_t cdev_id; > + /**< cryptodev ID to be used */ > + uint16_t queue_pair_id; > + /**< cryptodev queue pair ID to be used */ Shouldn't we say it is need only with ENQ_DEQ mode as described earlier. adding "@see" section would help > + uint32_t resv1; > + /**< Reserved bits */ > +}; > + > +/** > + * @warning > + * @b EXPERIMENTAL: this structure may change without prior notice > + * > + * Crypto event metadata structure will be filled by application > + * to provide crypto request and event response information. > + * > + * If crypto events are enqueued using a HW mechanism, the cryptodev > + * PMD will use the event response information to set up the event > + * that is enqueued back to eventdev after completion of the crypto > + * operation. If the transfer is done by SW, it will be used by the > + * adapter. > + */ > +union rte_event_crypto_metadata { > + struct rte_event_crypto_request request_info; > + struct rte_event response_info; Perfect. Other than above comments, everything else looks OK to me.