From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0083.outbound.protection.outlook.com [104.47.41.83]) by dpdk.org (Postfix) with ESMTP id CB76B107A for ; Wed, 13 Dec 2017 15:22:31 +0100 (CET) Received: from CY4PR03CA0106.namprd03.prod.outlook.com (10.171.242.175) by CY4PR03MB2693.namprd03.prod.outlook.com (10.173.43.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Wed, 13 Dec 2017 14:22:30 +0000 Received: from BL2FFO11OLC001.protection.gbl (2a01:111:f400:7c09::167) by CY4PR03CA0106.outlook.office365.com (2603:10b6:910:4d::47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.302.9 via Frontend Transport; Wed, 13 Dec 2017 14:22:30 +0000 Authentication-Results: spf=fail (sender IP is 192.88.168.50) smtp.mailfrom=nxp.com; caviumnetworks.com; dkim=none (message not signed) header.d=none; caviumnetworks.com; dmarc=fail action=none header.from=nxp.com; Received-SPF: Fail (protection.outlook.com: domain of nxp.com does not designate 192.88.168.50 as permitted sender) receiver=protection.outlook.com; client-ip=192.88.168.50; helo=tx30smr01.am.freescale.net; Received: from tx30smr01.am.freescale.net (192.88.168.50) by BL2FFO11OLC001.mail.protection.outlook.com (10.173.161.185) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.20.282.5 via Frontend Transport; Wed, 13 Dec 2017 14:22:23 +0000 Received: from [10.232.134.49] ([10.232.134.49]) by tx30smr01.am.freescale.net (8.14.3/8.14.0) with ESMTP id vBDEMOfn015203; Wed, 13 Dec 2017 07:22:25 -0700 To: Jerin Jacob , "Doherty, Declan" CC: Abhinandan Gujjar , , , Nikhil Rao , Gage Eads , , , , References: <1510210453-61428-1-git-send-email-abhinandan.gujjar@intel.com> <20171129114153.GA16467@jerin> <20171213112606.GA5166@jerin> From: Akhil Goyal Message-ID: Date: Wed, 13 Dec 2017 19:52:24 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171213112606.GA5166@jerin> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Matching-Connectors: 131576485435273105; (91ab9b29-cfa4-454e-5278-08d120cd25b8); () X-Forefront-Antispam-Report: CIP:192.88.168.50; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(336005)(7966004)(346002)(376002)(39860400002)(39380400002)(2980300002)(1110001)(1109001)(339900001)(13464003)(199004)(189003)(24454002)(4326008)(356003)(7416002)(65806001)(53936002)(104016004)(6246003)(2870700001)(97736004)(31696002)(2906002)(8936002)(67846002)(65956001)(53546011)(65826007)(105606002)(83506002)(31686004)(2950100002)(64126003)(5660300001)(23676004)(2486003)(59450400001)(47776003)(50466002)(93886005)(85426001)(86362001)(54906003)(77096006)(76176011)(8656006)(58126008)(110136005)(5890100001)(316002)(36756003)(498600001)(305945005)(229853002)(81166006)(8676002)(68736007)(106466001)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR03MB2693; H:tx30smr01.am.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC001; 1:P6LLNhUiyrHEX+bn0fcJxcHqabwiREqEF44+7YUim1exmv1XxdoU79XsY4Bew4ry/J9EjCGpYox3Yg8fYLvkwjOPDF6pn9F6baB3CJnT6W40at3yHtTFkFV71kfOu8He X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3854766a-8726-42f1-ef91-08d54234eda0 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4628075)(201703131517081)(5600026)(4604075)(2017052603307); SRVR:CY4PR03MB2693; X-Microsoft-Exchange-Diagnostics: 1; CY4PR03MB2693; 3:7lOED8pdSryJ1ub/kFuroqR0pN7HttQ3Ec3Vq3IWPiR0x2J/BW3busQT6ACGy42TLwZuSczssncwD2+yPLMFsUkd37gnCThNU4iM74h3Pe6ZFRuL8jUBzRSSDBpQ/VndGFXb2KvRaHkMDLMlQaTo/Cw2BvTCVc1oLgi3Q3VfrVROqtBPx0UTm4GiBCS/yYtSwgEaLkUjuumMgR+aj2Zwk6vIn0op/UsfLy4d1klUtUTHBzp2dWw2yUXPgF5YwtWXDJqqnvyy3RWZO5qcx8+3t1LFTF6qrxmmV7AtIm7Jdk+d2C9c1agrCkjI+HGK1jYtdQW5g4uE8/DtdhrsTxNeIdJ9oVHnstX/qTRkgUrp5uw=; 25:JSi3TMSeEDF0j5cmCRchWztVx0VMLnq1przTYsc2wjRF4L5L1mr6nEgwxGuUzmjJqRUAaOWSNdBiHkfFQUE4Ryuk9jGVpvWOG7HuDTEA6iENCs7hvGhyYf0Z7D2JWTKwOTX8GTtTt6nrxtlpN3sG7gHAf9cb8NgnxKYCzGZ42JtZyKThMteRX4gsQvccc0E0iGRN31/10OAbDAOPj8D39bE9X3g92fMwwyxCJhcPTXj7v0xbsZCqxctgiIH+Q+yWxkW8o0lgXrAO+wmLvEbz377hONwtmiWCp0Y/iJKOavzCpsBRc7x9glPDGHa6/iz8IPuMLQCl1PGuYfYkES5dXA== X-MS-TrafficTypeDiagnostic: CY4PR03MB2693: X-Microsoft-Exchange-Diagnostics: 1; CY4PR03MB2693; 31:ruwWtWUjYg9T/WT1UfHPzAXTJrGhuODiFo+2vZW3Tf4WA6RpbAriWM1rt2ZPE9CyKgM/TYHfQ9y9LR8lB3dVsZFhkGTf4BAI6OlaMFDjXyBFz3KqU3Kv5qhWCB5LNruLnLpEBAAzMRobn5Ovs7LSLF95VUYCu/YcXfQSENU6m/Yfi+j7EJf96uPY/vnJ+rRH9VppO3ZIh5Qzb5XdGXfOcJC72lgnajobSDf0zzFbnAQ=; 4:IUCStXHQWQWYXckJ/SPNxaWcwf27ktq0N9mnVOx30XRZunuIcojttmN57HqXM+ymUkpjd0A+MXgCu5fduej+WuQ2giSlote0J85zw2h65XBh3ZfFzRMiAqdJd2114aG530aTBPUSt5UeWSZftHkX9Ro1mCzhOfrMs+GCYvHhZ6S1YU5ApRBcoATk4k599mFu45TAJfPBgtiu62aqTlJ8Zk7R15a/aUNtTX1n+tlkCYKl7zLIudaNochfR8dxyRp6rYiVldz1UM2sHGETKx4PBRRsrDz5Ys3KjdrgGzOYtxfg49HLeukUUF958VTEcrEFKVJBiERNCj86D3/Snm312ifWnMSiasTg5ubslnMeUxk= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(185117386973197)(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6095135)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231023)(93006095)(93001095)(6055026)(6096035)(201703131430075)(201703131441075)(201703131448075)(201703131433075)(201703161259150)(20161123561025)(20161123559100)(20161123565025)(20161123556025)(20161123563025)(201708071742011); SRVR:CY4PR03MB2693; BCL:0; PCL:0; RULEID:(100000803101)(100110400095)(400006); SRVR:CY4PR03MB2693; X-Forefront-PRVS: 052017CAF1 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTRQUjAzTUIyNjkzOzIzOjkvVXBJWkxJRU1pU2JiMmtORDJSVUQ5eGE4?= =?utf-8?B?U2VXUkdod2VUR2Q2eUQ3bXpBK1lDTXp6cDVXM000bUcyWmhvc24rdm55cStQ?= =?utf-8?B?YmpKRDI2bW5zZUJ6ZWp2dU0xL0NpazM1M045aHlUOE5zZTlIamUzSWxvYXJl?= =?utf-8?B?WnJoVDFYWm1Da1ltT0RIcUozcVR5THBncC9PNXJsR3B6S3drLzJZM0dQcGNo?= =?utf-8?B?Q1BDRTdyU0xWNU83UmZMUEE1ZWhkM2NVQ0Rkcm5VREZUaEs4aWt0dWtCT1pn?= =?utf-8?B?RWwxSVNOVWZxamF2cEp0bzRvTEJLaEVHVWlWVzhETlN5aEw2NU0rYTNucGZV?= =?utf-8?B?OVBqNUJieTBwSkFueDlHYUhZYXprQ01CWGVxeWxLQzFkMVFSUjBheW8zYUFY?= =?utf-8?B?emVHUmtFNkp1dHhjNlpuZzB0ejk3YzdFc1RpM0pNVUl4dTdwQktLUXZIR1hX?= =?utf-8?B?Y1pROXQvKytjVlE1QjM5OWc0c3B6cXRtWC9NcjdWaFEvbU9SdVZBZEMrK2Fu?= =?utf-8?B?L2ZxdEkvVkZPNnJ1MzY2cjNkbHgybHFTK3k3bHNnREI3S3Z5MHl2WkdWSDlM?= =?utf-8?B?K0xoVjkrR2tvUlhRUU41NGZHQTFJeCtEMVlEOGlLODJZZ0RXNlBvSTRrZFZl?= =?utf-8?B?OXlOcVdzL0lpbFBnZXlPeDNTTjBVVVJxQVN2SDE5WUk5UlpieW5CZmgwK3ls?= =?utf-8?B?ZEM2VHVIYUxOZkNBRFZRWUduL2RXb2EvMm13eXV5V09kcE11UU1OZlBrY0Jk?= =?utf-8?B?R1lneFFBTjZRRG56SnVCSlBFdnFlc3VDUjhWSk9LeXdQNytqNURLSWVnNGho?= =?utf-8?B?VUtJMXdZeExudm4xV1FpMXBQWmtVWjRjOW1DY05hYWY4aEtnbkkzUDNRUklG?= =?utf-8?B?cTd0Y0h1emtrcDM5R3VRSE5Xd3hPMHdjVFp1VCtFTUpYSnlQYm5INjJRTlhV?= =?utf-8?B?WkgxN3dCWi9hTTRkMHMzcC8vZ2JRK1ExaWU1ZXg2YzdPQ2ErbEk4VU9UTk92?= =?utf-8?B?QzJvT3lNOVVCVDVPZE1xelVpUTg1UmNOSWJiMGNaREJQbW1YRUQwSDVFVkNq?= =?utf-8?B?MFVYWUtaWGhxRnErQzRwSlBXSzNUWlZrbSswRGtKcGt3UEQvV3FNd1YrMTBU?= =?utf-8?B?YURzcjQyZVVaQncvZE8wRnVsb3JjWlpRWVVPU0daQWcxRDJ1K0p2SHRIdTlW?= =?utf-8?B?eVhqVTVHUHNVRDNBUG11RnFHU05Lb2VDeDhjelJuNmovbzIyQjhNUStCSGs5?= =?utf-8?B?VXM1bVdYU0FPdzJ1MjQvWWV4bkt0aFBrQkorL091S0ZyNjhBRElIeHBtSWxI?= =?utf-8?B?NGo2Ny93a2E1NCtRc2svc0hUYkZtcXNkWUpjYUptZUZVMWpMbHhnaFF5d0xt?= =?utf-8?B?dWdQVmwrd2FncHZ1Q0ZmMVJsUXVra1JBMGJGRlhyTlQ5ZlIyLzNkWDBMclJx?= =?utf-8?B?RTJnUUs3MVhlQ2RFeFdld29ZV0cwTzY2ZHBsaXh1dmNTV2N0RWVHMmM1SFZk?= =?utf-8?B?NFBnWU5ZZHhmR2tBSW8rcll0KzlrQmxSVHVVWmorTHNKbitoeTdLU2ZVWnBv?= =?utf-8?B?cHJWTGFlMVNtWk13TUg3ZjhzUzlFQmpSeVdmTENzc2h2WHVJd0pmZERYNmE1?= =?utf-8?B?MUlqZ1NPemM1bkRhelY1Z1R0OVZpTDVoUGd2ekJld2JHQkhqSTFUQzhaeWtQ?= =?utf-8?B?QmhjcHN5TFI2dVhkcHZNa0xWY1htcHhWMFZ6UFhCSVY2MXBFSS9YbXdsWkxW?= =?utf-8?B?NlI3YTJsY2VOY0d1UnZ6UTVML1dJZjBBQ1ZaOHRQU2hOaVF4SnE3LytaOWNU?= =?utf-8?B?WVJqZElQL1lQL0x0UDRjZkova01paGUrc2ZoZFVFQWJibTFORGtCZ1B0UWVU?= =?utf-8?B?Z3JQMGdieEdUY0gyMHk1Ym5GWXhIRDAxMUJKL2tLUG5sRFFLRWUrWEhzVC9E?= =?utf-8?B?YzhFNlR6M0VBPT0=?= X-Microsoft-Exchange-Diagnostics: 1; CY4PR03MB2693; 6:Orf6Z1gG77ADL8tjSuqWglm1F1647a0lbkDSwVNNR5ZbIGl90FMDIIKtEQe+RWl++1XiRjxVcACJaaLn6ovlDBf/Rnv5Dztg+orqcnPLmfCIPmgrqjF/NBIdy8aROl8nDb7A4DIaLqLVPce/h0VQ5783kotJsR5rzmNwGqotwfRekzoayLgfV8JbXoDSgLyhbYRW31/2UMxeP8pAYNP+XFowNwUfNflSLIrIMIJHDwUN//UQcUI3Jr1uZ/BnVjf64pvDJ5avjgkuh5G+LeVe3MzcE7XtxpbUWPWXqp20i5FvFC9uQxCyx/320dfnT5KgwJ8YTVU8+uZcqjekTq5hVhY7K8uX2xFWwhKY3DMkEr8=; 5:krBJkXC4Nc1jn9swjgruho3RPufauymH25CC9acJkNVbS0XNPw4yUVxoXSVX9bs9a2+5I6+t6Oiel+g0w+2cUxhsADTshl5aZw31jVnPor/UNSU4GfBgOkAFs9a1jnWMC0J17UNiDzWNX/kkDG3hsW3f6HfSrzm7nV1wFDzg5Vc=; 24:UO9b2oRw8Fh/P/W8gYhyZCqJBzlGRFTqQicTuZnusS11L9n171LtkDcjwtAzmtNiqrT7Wy5GlM6H4knOywg5eE7VnnwdsbWKUYZ4sdhovfI=; 7:TvJXIuwaH5dKVrnVdiXlClc3wB3GvqvF1G1HgCs7S3ctq1lDJvd99Ze3tPkf0Ci7HpaNfKzrMaUptgoL31KzmBV5baqYTs/v9eFPv+ABV4jAxI6+3HpVwCt/9uQ4BW/73YXpWPwhsxFLxJNKyCrncKiEco5t+n9AQXM7n2J3sElccXQzPYdEm/mYaUEJ4NAI0htxiD3i5kmTqqphyQYAtqpFUKkpWfw1Hsdi+rda0sOHg+w4+hGwNVv30MhD+GvY SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Dec 2017 14:22:23.2777 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3854766a-8726-42f1-ef91-08d54234eda0 X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e; Ip=[192.88.168.50]; Helo=[tx30smr01.am.freescale.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB2693 Subject: Re: [dpdk-dev] [RFC] 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: Wed, 13 Dec 2017 14:22:32 -0000 Hi Jerin, On 12/13/2017 4:56 PM, Jerin Jacob wrote: > -----Original Message----- >> Date: Wed, 13 Dec 2017 11:03:06 +0000 >> From: "Doherty, Declan" >> To: Jerin Jacob , Abhinandan Gujjar >> >> CC: dev@dpdk.org, narender.vangati@intel.com, Nikhil Rao >> , Gage Eads , >> hemant.agrawal@nxp.com, nidadavolu.murthy@cavium.com, >> nithin.dabilpuram@cavium.com, narayanaprasad.athreya@cavium.com >> Subject: Re: [RFC] eventdev: add crypto adapter API header >> User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 >> Thunderbird/52.5.0 >> >> On 29/11/2017 11:41 AM, Jerin Jacob wrote: >>> -----Original Message----- >> >> ... >> >>> >>> Adding Declan and Hemant. >>>> IMO, RTE_EVENT_CRYPTO_ENQ_MULTI_EVENTQ may not be very useful >>> from application perceptive as the scope is very limited. >>> In real world use cases, we will be attaching destination event queue information >>> to the session, not to the queue pair. >>> >>> >>> IMO, RTE_EVENT_CRYPTO_ENQ_MBUF_MULTI_EVENTQ scheme may not very >>> convenient for application writers as >>> # it relies on mbuf private area memory. So it has additional memory alloc/free >>> requirements. >>> # additional overhead for application/PMD to write/read the event queue metadata >>> information per packet. >>> >>> Since we already have meta data structure in the crypto >>> area, How about adding the destination event queue attributes >>> in the PMD crypto session area and for, _session less_, we can add it >>> in rte_crypto_op stricture? This will help in: >>> >>> # Offloading HW specific meta data generation for event queue attributes >>> to slow path. >>> # From the application perspective, most likely the event queue parameters >>> will be different for each session not per packet nor per event queue >>> pair. >>> >> >> Hey Jerin, > > Hey Declan, > >> >> given my limited experience with eventdev, your proposed approach in general >> makes sense to me, in that a packet flow having crypto processing done will >> always be forwarded the same next stage event queue. So storing this state >> in the crypto session, or crypto op in the case of sessionless ops, seems >> sensible. >> >>> Something like below to share my view. Exact details may be we can work it out. >>> >> >> I terms of your proposed changes below, my main concern would be introducing >> dependencies on the eventdev library into cryptodev, as with this new crypto >> adpater you will have a dependency on cryptodev in eventdev. > > I agree with your dependency concern. > >> >> I think the best approach would be to support opaque metadata in both the >> crypto op and crypto session structures, as this would allow other uses >> cases to be supported which aren't specific to eventdev to also store >> metadata across cryptodev processing. > > Make sense. Just to add, adding a pointer would be overhead. I think, we > can reserve a few bytes as byte array and then later typecast with > eventdev api in eventdev library. > > uint8_t eventdev_metadata[SOMEBYTES]; > > Thoughts? I believe only 1 uint64 is sufficient. The metadata that we need here is rte_event which is 2 uint64 and the second one is mbuf. Since mbuf is already part of rte_crypto_sym_op, we do not need it. So only a pointer/uint64 is required. > >> >>> ➜ [master][dpdk.org] $ git diff >>> diff --git a/lib/librte_cryptodev/rte_crypto.h >>> b/lib/librte_cryptodev/rte_crypto.h >>> index 3d672fe7d..b44ef673b 100644 >>> --- a/lib/librte_cryptodev/rte_crypto.h >>> +++ b/lib/librte_cryptodev/rte_crypto.h >>> @@ -115,6 +115,9 @@ struct rte_crypto_op { >>> uint8_t reserved[5]; >>> /**< Reserved bytes to fill 64 bits for future additions */ >>> >>> +#if 0 >>> + Crypto completion event attribute. For _session less_ crypto enqueue operation, >>> + The will field shall be used by application to post the crypto completion event >>> + upon the crypto enqueue operation complete. >>> >>> + Note: In the case of session based crypto operation, SW based crypto adapter can use >>> + this memory to store crypto event completion attributes from the PMD >>> + specific session area. >>> + >>> + Note: ev.event_ptr will point to struct rte_crypto_op *op, So >>> + that core can free the ops memory on event_dequeue(). >>> +#endif >>> + >>> + struct rte_event ev; >>> >>> struct rte_mempool *mempool; >>> /**< crypto operation mempool which operation is allocated from >>> * */ >>> diff --git a/lib/librte_cryptodev/rte_cryptodev.h >>> b/lib/librte_cryptodev/rte_cryptodev.h >>> index dade5548f..540b29e66 100644 >>> --- a/lib/librte_cryptodev/rte_cryptodev.h >>> +++ b/lib/librte_cryptodev/rte_cryptodev.h >>> @@ -945,6 +945,13 @@ rte_cryptodev_sym_session_init(uint8_t dev_id, >>> struct rte_crypto_sym_xform *xforms, >>> struct rte_mempool *mempool); >>> >>> +#if 0 >>> + Create PMD specific session meta data for the destination event queue >>> + attribute to post the crypto completion event on crypto work complete. >>> +#endif >>> +int >>> +rte_cryptodev_sym_session_event_init(uint8_t dev_id, >>> + struct rte_cryptodev_sym_session *sess, >>> + struct rte_crypto_sym_xform *xforms, >>> + struct rte_mempool *mempool, >>> + struct rte_event ev); >>> + >>> /** >>> * Frees private data for the device id, based on its device type, >>> * returning it to its mempool. >>> >>> >>>> + * >>>> + * The metadata offset is used to configure the location of the >>>> + * rte_event_crypto_metadata structure within the mbuf's private metadata area. >>>> + * >>>> + * When the application sends crypto operations to the adapter, >>>> + * the crypto queue pair identifier needs to be specified, similarly eventdev >>>> + * parameters such as the flow id, scheduling type etc are needed by the >>>> + * adapter when it enqueues mbufs from completed crypto operations to eventdev. >>>> + */ >>>> + >>>> +#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 >>>> + * >>>> + * Crypto event queue conf type >>>> + */ >>>> +enum rte_event_crypto_conf_type { >>>> + RTE_EVENT_CRYPTO_CONF_TYPE_EVENT = 1, >>>> + /**< Refer RTE_EVENT_CRYPTO_ADAPTER_CAP_MULTI_EVENTQ */ >>>> + RTE_EVENT_CRYPTO_CONF_TYPE_MBUF, >>>> + /**< Refer RTE_EVENT_CRYPTO_ADAPTER_CAP_MBUF_MULTI_EVENTQ */ >>>> + RTE_EVENT_CRYPTO_CONF_TYPE_MAX >>>> +}; >>> >>> See above. >>> >>>> + >>>> + /** >>>> + * @warning >>>> + * @b EXPERIMENTAL: this enum may change without prior notice >>>> + * >>>> + * Crypto event adapter type >>>> + */ >>>> +enum rte_event_crypto_adapter_type { >>>> + RTE_EVENT_CRYPTO_ADAPTER_RX_ONLY = 1, >>>> + /**< Start only Rx part of crypto adapter. >>>> + * Packets dequeued from cryptodev are new to eventdev and >>>> + * events will be treated as RTE_EVENT_OP_NEW */ >>>> + RTE_EVENT_CRYPTO_ADAPTER_RX_TX, >>>> + /**< Start both Rx & Tx part of crypto adapter. >>>> + * Packet's event context will be retained and >>>> + * event will be treated as RTE_EVENT_OP_FORWARD */ >>>> +}; >>> >>> How about leveraging ev.op based schematics as mentioned above? >>> >> >