From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0053.outbound.protection.outlook.com [104.47.32.53]) by dpdk.org (Postfix) with ESMTP id A92DF293B for ; Wed, 13 Dec 2017 12:26:30 +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=P85+NRDr8Nbrl4NzKWqmbijNw6A6Cgyx8p43zxEQYA4=; b=GaorS9gK9QptKTFG3g8eKcJGH4sLYkfGPoBsr/e8YKhpdmdFKLjGvjcgdzs5e380RQZfBolasgIEt+QT1pWJTpQKLp/tn8tC0+d05wsp5g75X0UYi7c916s1PxBxS1VaJYCHZb0amdeaVJmasWryYLz2losiMzM8zY6tSqsDK/c= Received: from jerin (122.167.65.15) by SN2PR07MB2525.namprd07.prod.outlook.com (2603:10b6:804:6::25) 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 11:26:23 +0000 Date: Wed, 13 Dec 2017 16:56:07 +0530 From: Jerin Jacob To: "Doherty, Declan" Cc: Abhinandan Gujjar , 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 Message-ID: <20171213112606.GA5166@jerin> References: <1510210453-61428-1-git-send-email-abhinandan.gujjar@intel.com> <20171129114153.GA16467@jerin> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Originating-IP: [122.167.65.15] X-ClientProxiedBy: PN1PR0101CA0041.INDPRD01.PROD.OUTLOOK.COM (2603:1096:c00:c::27) To SN2PR07MB2525.namprd07.prod.outlook.com (2603:10b6:804:6::25) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a1551661-aaae-4d3f-0b6a-08d5421c5a78 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307); SRVR:SN2PR07MB2525; X-Microsoft-Exchange-Diagnostics: 1; SN2PR07MB2525; 3:keT93BkGpWbxGJis6TWM4XADX0Zw4dsQVQ4BJTbFusFlfcprz33Yg6FkQN+C8dKwgPcw6EUIZdBrcn67Zl4qc98IUu1tjbwUuw90uILatjFCV3lngDlm4jd6wHuNKbjJLKHTRujRLMvALZxUUFGqFzIlqdNwK4mz+qnhciCN9pw63VV0v50TlHZ6Aurt6VtXKDduVKnk1K/i5rY9v9ofyMVdsMBlfi+cdCa2PoOSds7rW1LVrvVSgiZtk9T740eH; 25:g7stYQrtUYzk5d66U/bOTKcWj+YeJiJoD5js/KUwlm2aLcAgxDVFX8GSzfbXQEmOYVM6Mp1EQ8Stp/EYeCbDZDRy/+W+c0rFH3K2vk/5AFdS9w4rbEmDjY9iLChlP1AWNvFfzQHrumlsin1nnF4i/z47lkPwd2dHztxHAwyJOmbHGDMp15pXa59WrG6Y3KPlRi3pXJvz1ljVfwOeW3k2Ly619T00iNEK8WDtsyDw1nw1yWhnv6/8JLrY8jgCaPNSqu8XwA1WKPDZQt13Z9kTJGyGCTeTUUa5nxz2LypbtKaqj9Ls14vRBM2MntYzc/LEBA0qS5tcjqEN4AXBoaZjxiLivzZ3SAezurTrScmS1So=; 31:4K5yXtp8YllzRI4E2+frO/gNqmjQt6ngw8ziONIMZkMmTUJm0UTW4AXIz1fl0BwzD+hCUxc5tsoxDuG42GTE+WuLWFAO2o7iSmgzsuNn0ycKNY9oFp5Ms8FqJSTG+8jzOStxRPFSjt+ooKwWCMUdG+opvadLOY/73aAlC1gLZJTYQtqbVlQG/Y+W6p6dP7zPXHhR+S3lqV19ut854Rlp1ocRM+/Hmr9aIwH9o6OTvM4= X-MS-TrafficTypeDiagnostic: SN2PR07MB2525: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; X-Microsoft-Exchange-Diagnostics: 1; SN2PR07MB2525; 20:AMCLQr0mfPLT7x8gRDRrBbgAykzh4ptGtISfOPxRAZr3YUSNxxR/a8Il2kdtbA0RwdFnHE1O2LRVu2RfKW4tyKph+jteg5e6OseLs8l8u7NLGHCAEWf7IrKghbxVxtUhMlV0tdJB8K5P9yyCynm0gsuuQJMzCFr2uB3sZl7/HNMRp2VzL8+BZlV8a5gGPnlZuep7QRcS6L5Z7IGd1mbbbi2MMESLUd56tCKV/N636Btj7VfUURCq4OJcFgKiDDRykP0+8oUgIg17bOm3p4aPd4QkJ0JuStv+RWMMY5v7hJGF4QjN9jAlXJBP97JsKgmdb+mRXv06mxfYliMlK7YEnzd0AhZwcjxGLBUZ6Hs009HZsJSMhwpFWO8KdSrNcbyA0oV6fxQfwSfwkO7psJDjIPtcAy7KoWlmY+LgxnpzZ0vr47tAz9cnnjCo9q9LOBlF+r95j+NM/jbbftLLQpT5fe5mMw97mZHbhact1BQMZb520fhUZIRjiM3pm5RZCAhd6Wi96FjjC04nai6iGZxNXnxX3UbOOqsfoI2h9o2gm+WgVsI/9DG2NyNkK2wLSpUsgUK4KUzwlBUV0K2atJVE2c+kjrrk0HbN2ZUHvV9CCJg= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(185117386973197)(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(3231023)(3002001)(10201501046)(6041248)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(6072148)(201708071742011); SRVR:SN2PR07MB2525; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SN2PR07MB2525; X-Microsoft-Exchange-Diagnostics: 1; SN2PR07MB2525; 4:vaMv6mRwBQkw2QpQ3DjLVzUIbMghF++WYHL0y+KoNOIDj/guhcos2Q1Knr0Pj32ofVOsT7eh4ldmCs/tLjqf2HBv3qjuA9Jw0YX5DosmYSE0Qzz64PXSCYkMoMPu1xoAu/8LGsZM/g1uBVGz4uC64YjDWyjN4sDB3yFytn8c7BSwMMlpf8uSOBRngPL9uQk0O0sYvcRiYglf/PILjJEw7Pb1tOI5OX9uQ0bravXeGfipObj8AtifkpdN+1c2ehyoZw6qlxPHGXt9VwAwv3skYybi6Rak6qGxidlRzgdnKRTZvAFxVGtGkcUpsU3k4LMl/ypmmZQXW8/GUNdC0jl+6m+P2mxyxOt5df1eDC6hHUo= X-Forefront-PRVS: 052017CAF1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(366004)(376002)(346002)(199004)(189003)(13464003)(24454002)(3846002)(25786009)(5890100001)(6246003)(81156014)(72206003)(50466002)(2950100002)(33656002)(81166006)(5660300001)(6666003)(7736002)(2486003)(53546011)(23676004)(6916009)(305945005)(229853002)(83506002)(42882006)(8656006)(52146003)(6496006)(106356001)(52116002)(8936002)(53936002)(33716001)(76176011)(478600001)(9686003)(58126008)(6116002)(105586002)(47776003)(68736007)(4326008)(316002)(97736004)(1076002)(33896004)(2870700001)(54906003)(55016002)(107886003)(59450400001)(66066001)(2906002)(8676002)(16526018)(386003)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR07MB2525; 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: =?utf-8?B?MTtTTjJQUjA3TUIyNTI1OzIzOk0wRkVuMlFpQ0VqS2QrdmRPVXFld2JxZldX?= =?utf-8?B?NWFlSzZlc0s0eit3cEtibzJXT2NyMnlSRFh0cVpNdDZXWCtsWGlTeWJpOHZO?= =?utf-8?B?ZGVHUC81UHpFWVJNdWQ1b3ljdDVSeDFjc1Z1MWlaT2F6WjVVc2RZTms4eVYz?= =?utf-8?B?SmJHWTVGL2ZGZGdzOHpFSWwyMGtWdmhkbFJMSTZJRVdWcWtpNHdrZkk1Z21y?= =?utf-8?B?dENsY0YrbTNLeXY2MnlRNmVYeXB0QUp5eUlYNCszWEhOZmlXaGZZdTN5WktY?= =?utf-8?B?ZXQ5NGxLeFBqTjlRQ2twWG9JYm4wYmliSmx1VmNwRWw0d05pTGw3TURnQ1l0?= =?utf-8?B?QnFHYm0rTzk1MEJYYTAxTVhrUjFFWW9OWGxnNCtOWHNjeExITE9md0JZdHNP?= =?utf-8?B?QWVGNjY2eHpKZUVPak9YWTFEV2lXV0RVQy9MbUV4U25wMFlKSXNvNUF1UFhP?= =?utf-8?B?MndGSVVabzNDaXRRbzZJQVJvMkN1UE9EWnorUzVXUmlpNDhhNUNld3lOdllq?= =?utf-8?B?UytyaWhjZmlwN3dEdWt0TTVMQU5CZEgyRUFSWFJGTDdEYU5YMnJ0L3M3RjRy?= =?utf-8?B?NzVSOVkrdUpjTXFhSU1vOTJySVBTWFhobExFSUdaeS9QWVpIMVVZOWZpWDFE?= =?utf-8?B?SlY2eVZxdU9YcURNeWRHNlFNWHRQZWp4WERBTkxDbnNQdnlSK3JEMm5XdEV4?= =?utf-8?B?Mjk3Y3I1RytrVldaR2hmY0c2QndHcnhWNFlRVTEwTzlIenR1YkhVZHdHamxV?= =?utf-8?B?SlV0Q1gwTVlpNHNLbGw3Nk5EWmR5NGlFNWJJUi85eW5WSlZvWE1QemhWQm10?= =?utf-8?B?R2Y0bVZyNVRydXFlM2lCVll1RUg3c1RhTXlNVWJUSnB3aWNvUUI0bXdUVzJH?= =?utf-8?B?YmhjOVFDMXgrVGFoVWlyaWllN3dpMzhzOC85R0Mwclpqcnk2SjNQZDNYeHM3?= =?utf-8?B?NGxMZVhZcmJKM2g1NkM3bk9TSEYyRWNudzNlU254QjBTVVVpOWw3amtoWTY4?= =?utf-8?B?bW1TSE5PU1FLTDZrMFRqVFhtVkdydWZlNk9mYXRoeTE5Sll1ZmRjenBRb2Zh?= =?utf-8?B?a3ltN0lLcUlkMDl3MDQ1WktjK3BLZ1V1UG1Od2pWazJnZXJ3MnQ1T2hjeElm?= =?utf-8?B?YmNtS21xa3poSVliNGl3OFdCVkpFSzNEVHFWNGdnSWVsQmd4TDB0SjlzVzVJ?= =?utf-8?B?S3FWL2lxTXQ3M2lsWTFPeDZ5N1pnZTljbUZ3Q0NNRVV5Y1I2ZzFPUEZEYmFT?= =?utf-8?B?M052bWx1TTVRYi83S2VvQUlVaHF6M1ZwZ0dqSUFCVU1PczJ3b3VhVzh1d1Nm?= =?utf-8?B?TmdzMXY5MkVscmkzZzZieVR4VXN0dFBZN0xhTGlCRjYvOXJJcG5pMFlNQitu?= =?utf-8?B?ZVhaenhXTzJTeVhXeXdoa3BkYmp3NHlDRDBZK3BQZXFXUFpaZVY1UklPQWY4?= =?utf-8?B?THk3eXl4bk1Ldkd4S3UxOURqeGNVLy82SVV3a0xSNWV3MlZrS3ZueU9DY1BF?= =?utf-8?B?UVowSlJ3RlNJb0ZUVXhPSjZ1d1pOWmZCQ0lzQm1PWE8vUFhXdDRVNDdkdWpL?= =?utf-8?B?QllvalJ3OEdTcjNwSXNVVmprdUh0Wkl2NFlUQkdZcWtrODBueXZ0ekRibDlH?= =?utf-8?B?bGdnYWc0S2ZNa200Qm9BTktvcElIQUJmL0dCV3lsbXBWNnFoMTFUT3pjTWRy?= =?utf-8?B?RmxhZEhVU1ZSYTJTdXQwOFh1L003ZklUaGtDUGhlakJlaHNGRlMrR1R5WjJw?= =?utf-8?B?Ky9MNE5zYmZjR2d1RUVtcS9HQ1lEZ2ptZ0RtL3pBQ0RwZS9FeWZvcGN1VzlP?= =?utf-8?B?Nm41MHBib2tSUk9hcnJIcENnNWYrTTh5dG5uSlc5c3dIRmxXTWNsSnhwcTd4?= =?utf-8?Q?rODCE0t4JmU=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR07MB2525; 6:G9PHJ+6TnqKH6AYfo3sOQUoi51qIUSAPNS+q7jTMRONY8CTJFKY7TTt7Dtyo4k4BWju8YHg0trLVU9AtAe4Hgja60apMLS327g24dnlhhcFXKoJXLaktvgQtIn9v4WSkcvSBPPKWxoqw9QqnqMkmUn0tG4ZsSIwF+Ggcv1lEYRCtc9agM16Ne4HrCqLadXcG4dZNvGUdpcwwarvimTfmh6pnD6DjM/KwM6dD5q9TjKo0/BIf/nBNw4you9gaFan6ez64IAfo4fLMyN8M6Y6BhEbKDiNrmsasT4T6e1k9bYjxSOdPTYdN4l7PhiP2xRPCZsSS1AxaF03hJBV9TQ5Ow8GMm72/PnPUxT9Cer9zXoE=; 5:Z9Ied2DGe8z+V635fr9K+ud2twhuiSr02Maa9U1YMGpWHvWfKhCQPrIrrl1n07wf6MI5oBnpqOYzhxEIBF9FhxZmbXrXfZYVq38CU0GxUc/c3Rypv1lA545D9a8OnLHS9Q0Egb8uLqh6q0JhLl5haOyknY1VCJspz9nv/Lq9HXM=; 24:ewUm9J+qgL5eX29FEWiBt0W9BcUr0v2c7MxLuH9pTBA7iT+cmc9eUo49DGlao50rDY6P+ipGxT7Dq5t8NloIbEvIqRMqgSAJLa3xZieE5BU=; 7:w4No7W7Pn7fxldNpVTO/fB3BSC/ja1D4bNYkxpM+xf61cQ4JCBcNyvYssLH/pc8D4ArU9Tt05z2oOu61ft8LEBU+OfApnxMicTtRVYIP3aEWqnY/+DvREK2a+aWEOpBYAsZbX5GRUxyuFUHEcMaSyJ9r13aeG3WGUGNzWQnygZzveE0wv9IhSwuP7qvjuCtKT5EiaLd40ixDqL2phBFdnyqa35mNLmMYiQQ9LKhmOFfnPcVlym7f27anIPIBE08s SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Dec 2017 11:26:23.9607 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a1551661-aaae-4d3f-0b6a-08d5421c5a78 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR07MB2525 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 11:26:31 -0000 -----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? > > > ➜ [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? > > >