From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0071.outbound.protection.outlook.com [104.47.1.71]) by dpdk.org (Postfix) with ESMTP id 1FD823421 for ; Fri, 23 Feb 2018 13:01:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SyEqeSLjWAueLvgCgjlqBf/EE6VkhlwPdVdogsBV7P0=; b=rUQgUMo2zEJvPuLmfNK9WwX2e+fdtOd86KX1zknqxS8NUZhJortURk55/1X1NK7wVUqCEETtb1Aol6fqm6wFkVGhBXfwDkl8V0IlZuvk+qo1MIsnz/kfNS+gm7Cwh9X0yVOFti4cBk4wHPwewyotaVE5QC1QBABWldzo+Y+bySI= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=akhil.goyal@nxp.com; Received: from [10.232.134.49] (192.88.169.1) by AM3PR04MB1380.eurprd04.prod.outlook.com (2a01:111:e400:536a::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Fri, 23 Feb 2018 12:01:01 +0000 To: Jerin Jacob , "Gujjar, Abhinandan S" Cc: "dev@dpdk.org" , "Vangati, Narender" , "Rao, Nikhil" , "Eads, Gage" , "hemant.agrawal@nxp.com" , "narayanaprasad.athreya@cavium.com" , "nidadavolu.murthy@cavium.com" , "nithin.dabilpuram@cavium.com" References: <1516013630-146114-1-git-send-email-abhinandan.gujjar@intel.com> <20180216193348.GA8882@jerin> <5612CB344B05EE4F95FC5B729939F7807069B737@PGSMSX102.gar.corp.intel.com> <20180220135920.GA23970@jerin> From: Akhil Goyal Message-ID: <9a982083-c5ef-bac1-754f-dd6bfb8c3a5b@nxp.com> Date: Fri, 23 Feb 2018 17:30:48 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180220135920.GA23970@jerin> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [192.88.169.1] X-ClientProxiedBy: SG2PR01CA0094.apcprd01.prod.exchangelabs.com (2603:1096:3:15::20) To AM3PR04MB1380.eurprd04.prod.outlook.com (2a01:111:e400:536a::18) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 8f66dc8f-a592-4bd3-c54c-08d57ab51d85 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060)(7193020); SRVR:AM3PR04MB1380; X-Microsoft-Exchange-Diagnostics: 1; AM3PR04MB1380; 3:mbBz9h54b+WYj6mbKnhPvGLzR0JoqPXXztBCYveXxkICNnbFAn01KQLvmMhmG+uj866EbjPwaTKBVy9v1EnJqb1XNyKJ0cWmEKS2PJQo14KoJavHtGQAupMO+s0h9Nem80mk8OZVmx4ykh2VcU5JZ1TQc+sUVccAvX3IWa3BXK/tEoWGtgRKKkc8k9DshZRNMNM7JwNGL9mXzNeyYmIyhPDh4BOIIJd2L+kESL9QWgW6dHXzX2bjIhhFu7p0Ngto; 25:IZVmV2c5LqQEQU1doTqgvNf6+Q0VWGiGdyvXt3m8bZcUWo9wZp1Z7LFf0zcL9rqGtubKH0q67qJslJFD2TOgoe5TVFtzmklZRsa4qNjGf3sNiIfj2MAc7r3qAKzrXfr1ezaZdGQAgdfbVeAePB/BGA/J7hoFzCeP+PnW9YHBgeg2Iw2uT706X3H1RJR1y2EGHtf72vOKNjHAfclTq0MdKINC5JyBOwthK2BDaJwcBSBDyBE4xOHFHB2gayhDs9LGtlWjftqfhD7ZjZDtPk+WjfII9At5aw6k55lQ2Ayq21sZ5dMeK+VqmoyuccyLtmFSTv4YOfDne1i1i6rhiscyNfD+L0seiSmzT5Y6lPfN1T0=; 31:9+GGE6Z9HzG7ggklsj4PhE8a6XGy07ygB6lma1GtclVm1VXDr9iqL/wPUhEcLdK9ghr2NVJIzx9YugP1laANORkrKHfUZpaK9PK+KiTNrnt+bOWMVR2+hG7IvWxeB4jmi+UEB9cKQ5VUdovX0pU1YJTsyd6Eqh4lzGnW7y7/zDSZ7857yVig8KNlfmdOB+KHXeIBw3KbZo2GeHmXjzWSZPzTsK1aKoNuWy/rOqL+j48= X-MS-TrafficTypeDiagnostic: AM3PR04MB1380: X-Microsoft-Exchange-Diagnostics: 1; AM3PR04MB1380; 20:oQtqj36hg200oeWTJBmG2Pkpah6LY/s8EyJViOKCGNNaYu80twNp3b45dmz9uN3s164N16AyciYDWkij+OrFXe0dMJ2KhCmIVmJSYPjvpJxdRsCpn5cLR5S/a9tZ2wGAylvIkiroHuJ2MpeR98MZDZ+hk01vR1FBCH42+766vfxgkXPST56Bpvxl8Y6YMaGDQlh5CeIcNLWFht5Qa70Jj0LubRBs2/kFcWSd+/sNaJJKUDXpWPONZJkN/gkxfXC5pmePe1LFIjNhAPXDouSOLkaRWO1WX9CMiygHKeucaar9Z/844fSAZHa9sUD4rWWZRLpjxiYuWB5Mt7L0wcfW1mv4flS2+XB38Ppfxtm0PKqgnEU4ZLCPXVz/8v9JrLQRYfAgpNXBe3KsnJLiJHNjOR61mOSL1WvWL8jPASBbH1sCBk6Zg/G2ICiDNrFczXnhb8wcvt3ziyUjhupeiXnZ+Z8uOWQcmoaE3pp3O9+bWMVQIFJCTEp/hqkVOZFRbN9/; 4:Qi8whquCACKrRQwTBnrac7p5GcfsH7Q/7okKAcHTbKDujmj0IGg0uiytD5NXm3c8u0ovPElFQrdKDTeJtVxtnrAxA5YgaD0E3UjK8slJ9ic3J862XJXoCt2vTl6Y8L9krwgP1Q5esP0WTSeMZCf4nZVoyH8WZlfho6NC6/RrOs+PzGrrkfuXTtvhBRMfnuV6/ZsTGZSFwQ3nQMQkEJTRKm2pJOSAS4iuEYwfU7AfqmwPBgsCoiw27hiQb7yxvff/dngCQvGuI5kgwsonzY75SApLH5ooQzqGzkKZWu9szegDH36XoRZ64XehoYCqGggNrvfTvuN0UwjmlaoZKsVBUlW64aye+F2IgCGE65MNe4c= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(185117386973197)(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231192)(944501161)(52105095)(10201501046)(6055026)(6041288)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:AM3PR04MB1380; BCL:0; PCL:0; RULEID:; SRVR:AM3PR04MB1380; X-Forefront-PRVS: 0592A9FDE6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(376002)(366004)(39860400002)(39380400002)(346002)(396003)(13464003)(189003)(199004)(51914003)(2906002)(386003)(26005)(81156014)(81166006)(77096007)(86362001)(31696002)(16526019)(186003)(8936002)(53546011)(229853002)(106356001)(65826007)(105586002)(230700001)(6246003)(6486002)(5660300001)(6666003)(2950100002)(53936002)(3846002)(31686004)(93886005)(59450400001)(76176011)(97736004)(8676002)(6116002)(478600001)(64126003)(67846002)(50466002)(52116002)(2486003)(23676004)(25786009)(65956001)(65806001)(47776003)(52146003)(66066001)(4326008)(68736007)(305945005)(316002)(110136005)(16576012)(7736002)(58126008)(54906003)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR04MB1380; H:[10.232.134.49]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTNQUjA0TUIxMzgwOzIzOkF3eSt2NzlGUWU3SjVmNnIxeXd0OHE2cFI5?= =?utf-8?B?YUl5UmJwR2ZaWWVEbjB5dDcyWURlbVBEamxkY21JWEZNMG5HVklpVksrQ29a?= =?utf-8?B?eTNhVy9TT2RlRnoxR0JLeHhWcjVZVG5lOUQ5K2hVTHc0YWtPTlJiY01iQVlr?= =?utf-8?B?V3ZoUHVTNEhibkhSdG00UWVFd1MxcFc5WTJuR0pCNW5jS0U0OTFaSXJvd3Q2?= =?utf-8?B?WnBYM1JPczkxWHVUWUVDS0dPR05Qdk52Lzhldnd6NzFTZkcxdGxRNXcyUVc3?= =?utf-8?B?UkhyQVNqTVEwNEN0bE5rZkxabTBvaUZ1MFluc1doajJ1eFNiOWc3M2p3OCtt?= =?utf-8?B?NCtHV0ZaTGRISi9pQjF0Z2hMaWFFQjFURUVPV0p4c1lrbEVhdy9FNjlEMTNQ?= =?utf-8?B?Q3hWZ1MrNkVqZkRWdU1KOHJGVjNkVWtoR09SN1lDNkxJQzlBZTNnSnFCYWVP?= =?utf-8?B?VW9rcmMwdFc3eXZyMjZQYUgxZWdBdW9EL1dMWk90Zk5mK3QrMXQrSWRDSmY5?= =?utf-8?B?R3BsdUcyT1FOQ0lZaksrWVFlYklxMXpMUEZyaGVrY2xWVVJzOEJCMVVrOWlW?= =?utf-8?B?Zlg2Slp1dG9hNURaV2p3MGFUOXlMSnpkdHNncTNJMFU2NXE0dktPd1pKbFF1?= =?utf-8?B?TWFWYlVDQXptR1FXNlJJaTc4bkhCWm83VnFud0FEVlFDcTh3Z1pvWHZBcCsw?= =?utf-8?B?aDduSGNjcVpydHhXRTlrb2VBdW1LUitaREt0TlBHRFovSy9UQXBuOS9pYnpq?= =?utf-8?B?U3FJQWFIV1lqVFhldy8xcTZNaGtSUW9zRzZXR1BFQ2VyaHpVVWdwcjRZbFBa?= =?utf-8?B?bDRrbkZkQ1R5WmhUb0hRSTY1UVUreWplUTQ1aHM5bXA1bDJIRTJaYnF0ZzlL?= =?utf-8?B?ZWdpSC85OVZoSDFjLzhaQXE4Z1dWMDlJTGFKRkxMTEpuM0xUVCsvbmorQTIx?= =?utf-8?B?TTFPQjhZcEZmbDVZS0pnYWRwZU1qSHhodTFDN1VBOWpXR2dyWXN2eEVZYnYw?= =?utf-8?B?NWw0Q21Ed1ZOR0FjYVJ0QklVemVBUHZNYkFRdVAzU3pnV2FsRlh2Z1FpQks3?= =?utf-8?B?SEEvSlpEL1dpV01RZTF5NDRmYzVKeStpSVFWVVY1cWRJKzhIeHlyMVVEbHhq?= =?utf-8?B?MmdyaFhMWFhRM2sxbmQxQlBnakR4dFEzS01mSzFNSnJmY1g2bTJBSklqb2c5?= =?utf-8?B?elYvMnhRelVhWTFtZ1dOYTdXelZSWFpJdjNMTmJWalJHajgxK1pKSHFsdCs2?= =?utf-8?B?NnJMN2N5VURJeUVFRjVaSFRzVUdCRXhrTDRLamgyR0pDOEliY2FFeDc2dzhD?= =?utf-8?B?cjlmWE5PanEwR2tvWHlMZ0dQazJsTkVTMTVBdnRjcnNSMWRPMERaNWNpY1Uz?= =?utf-8?B?L0xLTVkybkVSSHRSZDA5aXA4OE5KeE5iL016MVdDU1lnVDgvV0EwVnUxQmtw?= =?utf-8?B?Y2F1K2dTL0lkbmFMcUkxWXV2VldpUVV4MHpvNkZlOWJUbTJLK0lHMTlRbk5M?= =?utf-8?B?OXdoaTFXSWxzbGZVbWxhTTFWd2xjTWxyLzdIc0E4Y2tKREc5ZGJ6KzN3dWxF?= =?utf-8?B?Q25kUXE5M0VFbE9QdHhabDlGN3RrcjdGVXlydHN2QmtpT04ySGRCN3BZNFdH?= =?utf-8?B?K0dMNFd3U1p4TUljMUZPN05kMFppbXFxS3FpWm5obWVJMHJHSytKS2ZMS0FW?= =?utf-8?B?MDRjWDllWFM1Rm1yb0ZDU21leVR2b3JtSHJjWnZoNTQ0aEk0SGhKNjNwd3JT?= =?utf-8?B?MzVHRnpKNW9pR1RtRXBwM280RTZNcS9tRE1JbWtBK21FRGc1YTY1a1pidzdT?= =?utf-8?B?U1lJWWhqR0FQdlN4bmV3TGpDbXM5Um5EQVI1NU9qdnhIMEZsSitndytRc2hv?= =?utf-8?B?b1BSZ2Z4dUEzaWRocGx4Q2ZmQmNQNmdKS0hMaFljYmFuY1RwUFRMcGxJZzdj?= =?utf-8?B?ZjMvK1JDMnlxZkF5MDRIUXJEUWxyc2NWN0pUNUdtK2h1UHlCYmRVYWlqcGxZ?= =?utf-8?Q?JiBXTr?= X-Microsoft-Exchange-Diagnostics: 1; AM3PR04MB1380; 6:qrsQ0NRl/URFfxCR/TGmkaTCNwG92ApXjremn0HYO9L1Eaun3/XHpc9uKO7AFs0ekeKif0Lf/HP6mXzYZDLVU/BdozONrVROyPnKzqs0+B4ROfClwjmvZXoiXLrcPaHEnPeLufTB7FcfeUKTsBkl9d2YBS4WVizanOSw7dqrrGmUN7s3joLFAIumy4q/BaAQYkP5cJBHLdPxQc4HR/3TAcDnt0TtTitI9/iIi0XhBwZz/LpAof1/KQL1zw25pIGuCUnnwwQmVghbz7OdnLO2/gtX2ccgmC6tL8hxSj/KXwVmu2eVrQK5K99+BwDJjecyUHMvDD1hxe5aRFFwrhn3WGcDQBOJAk/XRZFngmNOxBM=; 5:Wc5xRZ1Er1v789YCFBfKZ69vA3U7h3woghO4DAaLnBJGmzy7gWwYr/pTa78uE182InXkeE9z4/LX77vbfOMwRthPt16zvPZWQChMTXpUpGAM5vCyt+8C2SOHrJZny0pF8pk+umxzl4zUlSfHpEBqYQhSggQ05g0clIP33e0taz0=; 24:B9N8RkaNHHI9hrB+FdlavcLjpiYbKwJRLqw1bi43D7fkJcoo31jx38M4EQHr2JRRgdCZVASjsd0O4gGCIGPsOvGmuIsGTGVi1Ruo6PXg/8U=; 7:0SWfp0Kv6KgHFIswDXrSBCP3Y4QWwnO5QsMgn1DFFgIAiVLBBjsNxmyiknpT1avia0JHt0rREuZBeh918C5QRnqpAFzWA4nLqbsvUhNORfjNYY1rJ3XRmP2m/wX2UT063lUdUtXKJc2xJdugI9cqBPOzM/CmeShKdmKZUhN5WwliCP6tOrDwrxpwkMdb5WXshAUrWtEnvqc/f1rcQnuimiJ+uolEdNTJWdVCVKqnsp3cClocfGH0lqr8+O+4IyfM SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2018 12:01:01.5611 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8f66dc8f-a592-4bd3-c54c-08d57ab51d85 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR04MB1380 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, 23 Feb 2018 12:01:06 -0000 Hi Folks, On 2/20/2018 7:29 PM, Jerin Jacob wrote: > -----Original Message----- >> Date: Mon, 19 Feb 2018 10:55:58 +0000 >> From: "Gujjar, Abhinandan S" >> To: Jerin Jacob >> CC: "dev@dpdk.org" , "Vangati, Narender" >> , "Rao, Nikhil" , "Eads, >> Gage" , "hemant.agrawal@nxp.com" >> , "akhil.goyal@nxp.com" , >> "narayanaprasad.athreya@cavium.com" , >> "nidadavolu.murthy@cavium.com" , >> "nithin.dabilpuram@cavium.com" >> Subject: RE: [RFC v2, 2/2] eventdev: add crypto adapter API header >> >> Hi Jerin, > > Hi Abhinandan, > >> >> Thanks for the review. Please find few comments inline. >> >>> -----Original Message----- >>> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] >>> Sent: Saturday, February 17, 2018 1:04 AM >>> To: Gujjar, Abhinandan S >>> Cc: dev@dpdk.org; Vangati, Narender ; Rao, >>> Nikhil ; Eads, Gage ; >>> hemant.agrawal@nxp.com; akhil.goyal@nxp.com; >>> narayanaprasad.athreya@cavium.com; nidadavolu.murthy@cavium.com; >>> nithin.dabilpuram@cavium.com >>> Subject: Re: [RFC v2, 2/2] eventdev: add crypto adapter API header >>> >>> -----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 >>>> >>>> + >>>> +/** >>>> + * 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 >> Ok. In that case, adapter will detect the presence of HW connection between >> cryptodev & eventdev and will not dequeue crypto completions. > > I would say presence of "specific capability" instead of HW. > >> >>> >>>> + * 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. >> >> /* >> Application changes for ENQ_DEQ mode: >> ------------------------------------------------- >> /* In ENQ_DEQ mode, to enqueue to adapter app >> * has to fill out following details. >> */ >> struct rte_event_crypto_request *req; >> struct rte_crypto_op *op = rte_crypto_op_alloc(); >> >> /* fill request info */ >> req = (void *)((char *)op + op.private_data_offset); >> req->cdev_id = 1; >> req->queue_pair_id = 1; >> >> /* fill response info */ >> ... >> >> /* send event to crypto adapter */ >> ev->event_ptr = op; >> ev->queue_id = dst_event_qid; >> ev->priority = dst_priority; >> ev->sched_type = dst_sched_type; >> ev->event_type = RTE_EVENT_TYPE_CRYPTODEV; >> ev->sub_event_type = sub_event_type; >> ev->flow_id = dst_flow_id; >> ret = rte_event_enqueue_burst(event_dev_id, event_port_id, ev, 1); >> >> >> Adapter in ENQ_DEQ mode, submitting crypto ops to cryptodev: >> ----------------------------------------------------------------------------- >> n = rte_event_dequeue_burst(event_dev_id, event_port_id, ev, BATCH_SIZE, time_out); >> struct rte_crypto_op *op = ev->event_ptr; >> struct rte_event_crypto_request *req = (void *)op + op.private_data_offset; >> cdev_id = req->cdev_id; >> qp_id = req->queue_pair_id >> >> ret = rte_cryptodev_enqueue_burst(cdev_id, qp_id, op, 1); > > This mode wont work for the HW implementations that I know. As in HW > implementations, The Adapter is embedded in HW. > The DEQ mode works. But, This would call for to have two separate application logic for > DEQ and ENQ_DEQ mode. > I think, it is unavoidable as SW scheme has better performance with ENQ_DEQ MODE. > > If you think, there is no option other than introducing a capability in > adapter then please create capability in Rx adapter to inform the > adapter capability to the application. > > Do we think, it possible to have scheme with ENQ_DEQ mode, Where > application still enqueue to cryptodev like DEQ mode but using > cryptodev. ie. Adapter patches the cryptodev dev->enqueue_burst() to > "eventdev enqueue burst" followed by "exiting dev->enqueue_burst". > Something like exiting ethdev rx_burst callback scheme. > This will enable application to have unified flow IMO. > > Any thoughts from NXP folks? I would be replying on this on Monday. > >> */ >>> >>>> + * dequeue only (DEQ) mode and the second as the enqueue - dequeue >>> >>> extra space between "mode" and "and" >> Ok >>> >>>> + * (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 >>> >