From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <akhil.goyal@nxp.com> Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0063.outbound.protection.outlook.com [104.47.0.63]) by dpdk.org (Postfix) with ESMTP id A037B1B05 for <dev@dpdk.org>; Mon, 26 Feb 2018 14:52:13 +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=1DKFwmUsBXURwm5M+kc9ZyqpNDfKQ8bS6tJDmCxL9mg=; b=QSc9wMnNHKfBA9rwVTymZUx6UK6mB64L7CZvL2bjKNcG+XlRr2L4Lhwh3UEfkrEni6wJhIvuPH/qeaYazkJ7C1z+2kF2yUXEDYBVzernP6ipL5VN5Ut/5xFfpPVsuhibKum3I0YbjwVGH+jFw4uvjbVmrcR5NzJL8Yow612Q6cI= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=akhil.goyal@nxp.com; Received: from [10.232.134.49] (14.142.187.166) by VI1PR04MB1391.eurprd04.prod.outlook.com (2a01:111:e400:5348::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Mon, 26 Feb 2018 13:52:08 +0000 To: Jerin Jacob <jerin.jacob@caviumnetworks.com>, "Gujjar, Abhinandan S" <abhinandan.gujjar@intel.com> Cc: "dev@dpdk.org" <dev@dpdk.org>, "Vangati, Narender" <narender.vangati@intel.com>, "Rao, Nikhil" <nikhil.rao@intel.com>, "Eads, Gage" <gage.eads@intel.com>, "hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>, "narayanaprasad.athreya@cavium.com" <narayanaprasad.athreya@cavium.com>, "nidadavolu.murthy@cavium.com" <nidadavolu.murthy@cavium.com>, "nithin.dabilpuram@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 <akhil.goyal@nxp.com> Message-ID: <d9cc6973-4a49-a8c3-4141-cfa589b23139@nxp.com> Date: Mon, 26 Feb 2018 19:21:55 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 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: [14.142.187.166] X-ClientProxiedBy: SG2PR0401CA0003.apcprd04.prod.outlook.com (2603:1096:3:1::13) To VI1PR04MB1391.eurprd04.prod.outlook.com (2a01:111:e400:5348::22) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 5ec73238-b0a1-4bd0-46fa-08d57d20224e X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(2017052603307)(7153060)(7193020); SRVR:VI1PR04MB1391; X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB1391; 3:NkTgBGG0SdVHKfXednjyZqCCKWcbD6VMTGmX8nn72yjDR9FSBTZJDDMhLlFAZR/oT9SG3CSNOuI+wwPw7WPVL4Al+ygV1vUQHVkjfKSXsJCdwAqclt0jnFlk+0TylpCRbuDoDHYW6kLsxiRer7sTMyG1dJIkyrDtT9RbQ2RV/Q0bU9cYIqmBoJrsEWyn7A/47yiQQeGv9whcEV5v5GPM5NAiGV8+R6n8EaJYDcRVvDmHJGwl2aWMFKPNlf9BndTu; 25:61N+0zrfvIgZRfhYS0n8+yhtDv3It82sva1sZB3W31qb6kWGtKBiwenfp/uXJtqD/ch1qW+c0V0V9V37cqCG1Y+UHg3LHOukxgrpNdax2QER9Amd8p/lerKTEidq8fY2amrbJ71qTRpRzOEi6MdSp7M9AX4FUKThglyvHWxlLkWNDa3LWMyCzNTCs9cd+7f13Pwv+tNC0Q7zn7n0GNF05yx5opOKZ9MZAs5yecO1zal/QzdrSW4vC9i4is1NxCrGYJ2Udgeyo3EWZFEwPdSEG0NKWt+tUUx8euEnyqpzVJImJFiVWvWg7gLAYTva6OGd+Hajq3egnuQCVfhSLHYteA==; 31:oJhD/iXWqM1bVKwAP+MuhxG6NtC7MYwGBHqjKqBAyR0lUVA8+GSzIB2ysiPDkiL2cdedoBnHOvNyStsdBokjnnSPSBfUM13jOSLAsGvulEfkDit8zEiBgFohn8y4uzWfbnAx3jTdMqHWQFF8sXipjqSqFkcF0pOtWheJoazCXhdvadp3vxryNe3E+2LOp/H8d9i4uY65ka7ff1Nw6EA8n9PZTQHz5u5Vk7dA+mUG0Po= X-MS-TrafficTypeDiagnostic: VI1PR04MB1391: X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB1391; 20:sVLyEZtAlCm2S0Lwlj6gY97XKFWYN9xouQVNJFeUtO2Smo0Ph4EX0Rw/Gh7HePfRbI316sYERfXrrjZ754XWDXxuqFJ/2GsQOFCjb5NbqiuJN9kO7JEG6zaujd6xAJr3qlkxSDaqzFFo/tGhe5J2FGplVGWHDz3mSgi/WEJoaNUPMVQ4AVt5aCzMgjPlZ0GsM/3uoVu0udyygQbdoKO7SAye4dso/vOew0Cn4lp3ojRCoRRvcfp+roIolzFK2Jy7qilHYOvlZPM4chP410j0u3ioUXc4wY8Uw2RZ6RG4hljecUZhLX49JEznpUew87Mr08vEk8rGxIxPIoakkLtPWLIJloNeF75sVG7NAKpezH9sJR+G4Jqe2riT+5HwkKM1dOZFW2w2iCmDkWGKNC3yTNH/KyXQIAWbCF8wZTJojhiS5XGYffLJfGC4xhROMQl0Swj2/q5sK7Uez+i0X2zG2nzsid8LzNSN3luv6ISwCBzYSjFtW2nQ2qhDEiDYJHsd; 4:+It38oj0WtN5/+IG9oo/auBbezDNBQtCh0Cp2o+Ti6bOvt1xta9jLEGAC5/09EiuQbmIi0iAT4u+tJp8FbsNV8KOV/tneoC9rkwiy2/GdHX1N1ybJfcd60Qf673ZviUGHYGA3GSIlYrAIR5a0BARCTsxo+s3A5QJDa8QT9MKeq8IndHj+O8CtHNF5IyM6kAFmb/tJ4aQu5TvZh7F2MgPggCDyWnUYSAi+caAu7t46XblGJSkYBSyiaBmW1g212AeH4NeOS6McMNJjJbKtLBNrTVPTtPK9KKQY/MKkLtlw3woJkuBj5e7QcI+/21y7B5/2datqfHoqCa0VE4H+RMbWwTZNPqOdFPH/3TrzPZYzS4= X-Microsoft-Antispam-PRVS: <VI1PR04MB1391450151E7B598020D4079E6C10@VI1PR04MB1391.eurprd04.prod.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:(185117386973197)(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(5005006)(8121501046)(10201501046)(3231220)(944501161)(52105095)(93006095)(93001095)(3002001)(6055026)(6041288)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:VI1PR04MB1391; BCL:0; PCL:0; RULEID:; SRVR:VI1PR04MB1391; X-Forefront-PRVS: 05954A7C45 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(396003)(366004)(39380400002)(376002)(39860400002)(346002)(189003)(199004)(51914003)(13464003)(55236004)(23676004)(52146003)(25786009)(5660300001)(2486003)(59450400001)(81156014)(2906002)(81166006)(97736004)(105586002)(68736007)(386003)(53546011)(36756003)(50466002)(186003)(26005)(77096007)(16526019)(4326008)(3846002)(6116002)(76176011)(230700001)(8676002)(305945005)(5009440100003)(86362001)(52116002)(7736002)(8936002)(478600001)(6486002)(31696002)(67846002)(54906003)(316002)(16576012)(58126008)(110136005)(6246003)(53936002)(6666003)(64126003)(2950100002)(106356001)(65826007)(229853002)(31686004)(93886005)(65806001)(65956001)(66066001)(47776003)(110426004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR04MB1391; 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?MTtWSTFQUjA0TUIxMzkxOzIzOlltYnN6b2hhTjRtRzdzOTdMejlvb3hSVDBV?= =?utf-8?B?L1B0ZmVYamd3TDJHdVUvVkZyMEQvMmtYK3ZUUUhQR3ZSbXBacEhtVXRTNEsr?= =?utf-8?B?ZHR4YVV0VHhkb2htc1pOWkpMWG1oaE1wcUFXUzFNdjd4UG1nVEZnTXRYYzZm?= =?utf-8?B?b2hVWGlFSHFTeGc2MFJvWU9WV3BtRXIzRm9jVml6VUgvd3JVUHYxZEtpSmQz?= =?utf-8?B?eW56NWlFeEI0NXlFdjFQRE1SdWRZMGoyQWFQdW1kUkV5ZTJmeTVhRDc1MnhZ?= =?utf-8?B?bXpuSXd5cFdycHczcCs5ejJwUVFpQ3ZNZnlXZmxrUUxMMzBmUVBHV3lIVndv?= =?utf-8?B?ZFFtaHMwNGduT2VnQVJwWHM5SnoxQXdkK25EQzdoekRvVTNxNFJxclJkdGdK?= =?utf-8?B?ZUdDOXZHM1VPeTBWV2kyZWZjcHJOQmhQWWhjQU83RG1rT3h3Y2FZM3Z0N0F2?= =?utf-8?B?QytNNDM1THhQZlNOZnFGVk5iK3NkRTVHcjlWZ3M0MHNEbzFhcDlKVGRMOUZT?= =?utf-8?B?bFJ0WXg2OGhwQVYyYlViTkN3MXdzYXNOWUNmOUR5TjZ0N2p0VVczZjlyUFBn?= =?utf-8?B?WDhRaTFxa1lCRlM5SEd3YmkvVXEvc2JjQ1Z0ZmlqRHRtWWxpWjFnbittOVc0?= =?utf-8?B?cXE1NVhkL24vSWhZcEN1NVNHSkFnL09NaEVoZmc2cnM0RE9TRnloTFM3QUZL?= =?utf-8?B?WllmeHJmR0MxdVJid0NnWmdnM3ZzUmd1NkwxQ2YrOXV5M0dnQVRIbGVjS2pi?= =?utf-8?B?WTJxQk1xSzdjL1NlWGxMWWdmd3M0allNZEROdXF3cmwrNnlRamNwTWJrNUxy?= =?utf-8?B?WkZXVEJKZTY0bE9qcUZIRXV4RFhEamJXSWtnRTRYSHZPT0Nwdjd5RFlOOXJa?= =?utf-8?B?Q3YwNXJOWFlVSUFYSGlTSUlRMDRBcVp4OCtMRmV1Q1AyTXU2QUlTamYxQlVx?= =?utf-8?B?bTI5R1NZUFpnMzJnY3J0R2NRVzdtNlVvL0ZmQ1NrdWFITTRRZnkrczF5eG91?= =?utf-8?B?aS9DKytzWEtydk1lRXoyRnJFcjY1U2FoSDNHSWZuWGFIKzg1RHgyQ2xhMS9j?= =?utf-8?B?YU9JT2M5c2IrMG1wZ3J3OFVwWHBvY21Lb1RsZnEyekdrbmV2UHhQKzZjNW9E?= =?utf-8?B?b2xmM1pYSFlCSFkyc1dvVGNVRUJwbGdSRkxFeHk3R0VtYXJVcUlNYWc5dzh5?= =?utf-8?B?ZnI2NlRxNHZkNFRQaldzNjdoLzRIWEIwVEZTMzZaYWJxb2ZXWDRTd05zK25D?= =?utf-8?B?VTY5Z3dtUjFIcmFyUndPcmIvWmN3UWp1VERsL0RIdEF1Ukx2M3JRVmhMNWl5?= =?utf-8?B?cUhHVEtuZ2x5UjkxcjRMK3p0aTBrWU5pZmZTSmttd0lMcEVhM1A0K3hKOHlO?= =?utf-8?B?bTBjbmJKa1JOQWhXRWp0aTVWVUd2QWg5ZzFPemprdVRlTnlvbE5RYjBjVzQ0?= =?utf-8?B?alNPNXRacmp3RGs1VUR6NmdoWEpYekdNaTA1NWFUOTBldjIzTEc4VGtId0VT?= =?utf-8?B?NVc4TGo2MVhrc0FGTmxpaTdmY0tZWUorMUdIaVJlVElISVJHczk5RmU3Z3Fo?= =?utf-8?B?N3JFZ3hnZXRQYVZsS0lMeno2M3JJRzk5STJKVXRQc2d1SUR1cHozSjMxcWhC?= =?utf-8?B?ejlLcVpNRUZHK293NFl0Y1RBUnlCeXc3N1FPRytGakFLT2g1Nm9JcjArd2VY?= =?utf-8?B?MWJRV0QrekdJV0M3UDFBRkhoZEw3b3RhQnBaa00rVjV1NTNHcFFXNkNxYStz?= =?utf-8?B?a0c1L0x0cWszU2cyamR4VkMvdFpmdGM3UHBQakU4aWVDTlo5ZC9NWVFwdGla?= =?utf-8?B?MGxIVTFYWlBwbDA3eVdLWVJJeWN2UHFseFhlVU5TYU5lZHJYNFpodllBWU0y?= =?utf-8?B?bnVOOGVpNS9uQXBlaUpxV2d0YVREaW15VDBnZWRuTEJRMU13bWJ4RThKZmk5?= =?utf-8?B?L0pPVEVHZHVRRExOV3Q1YlBDUUJTSG9BYVVCaXdBcDZXZHoybDVWVjJlRVJ4?= =?utf-8?B?cnpWdVg2cGYwako0M2U4VTFTR3dmUlJ5REgxenRuMGY5azdpcUlIV3c1V0dX?= =?utf-8?B?VENwK3dKMDdDQkNXaWYyQnlvTm5FTUxQTjNPZmV1WnUxMWJyYmZ4emU4eWdH?= =?utf-8?B?RHc9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB1391; 6:146dkzJJFzzchmipVu2XAoUri/gH9NqC7xfQemTRacoxV/GFmoSWqpJvJ9ySm6VCueeqTFC3Vgn18SwQpnhTTjeoRbOW7H4Qg6qzj+0m8eCD92AGv8ac+kB38v7tSiaztMvaio2h9kx4CVHbgxopAGrDxB8CIML4vm0aHiPrP1Eemqt5Kq3+5e3AY5OEfMOSLP92G8ydhOldSOd8w9jEN4+eDcbzNVYJaUcdxjkWakQ+u+Xpn+L3Y/l/FmXwANRGkiwUfpDec4a1wk3uCoGNRTd4tArCuQnrKqGJCSWbLZU/YL644n8L+GMMGmS3+wts6bUuEHjQdDkP9/TcI6x13A9nEDaaOmb820+yzPx9DNc=; 5:uM+exh6nBjQi8sDupvZo+ShiSVw3o+UlLZgGTMw7t1MWMUTOKhQgwCk1kgJSzGFxG3wvtpRwhHiCJLZKAstcoJQUnhig/tVxNSZg4tmNjgS3aCa8XU78wEhVGniuIqPflsnraXyf4r2YKdmgkRIygSsU4xMw25EAY7su8X8YCCo=; 24:Cn4zt4SnTvFuRA3ZJPoYJ1DuamcjE47lr2P58XGwNfjIczOeVxTPEJH/iNZd9wCgBAsIXO8gsGa3KQ1Y5C/elTzXbaozyLv+v6DlKNaMBYQ=; 7:QtHmRYhT4rbL1armNITdQTZ/x7uWYW35YkwoH6uzoL/hxqgynTZHDTl76BaKTmmty+OuJuKPSeo0Pk6vVljC/qtbdkuyAlET15LnUHZ8fg9Ox1IGRno8UjMbJnmTEzIuhzt34qkEt28kLc7KId1A9Hjs8eeKzIkYsP6e1hTMNzIcgM73lBebuZNcfqmQ4exmigy29tOogr0XQzmqSCEnQmTByLo0f5ALyE6RZwWyn4xjc6D8L+JR49hie72VwbP/ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Feb 2018 13:52:08.0772 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5ec73238-b0a1-4bd0-46fa-08d57d20224e X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB1391 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 <dev.dpdk.org> List-Unsubscribe: <https://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Mon, 26 Feb 2018 13:52:13 -0000 Hi Jerin/Abhinandan, 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" <abhinandan.gujjar@intel.com> >> To: Jerin Jacob <jerin.jacob@caviumnetworks.com> >> CC: "dev@dpdk.org" <dev@dpdk.org>, "Vangati, Narender" >> <narender.vangati@intel.com>, "Rao, Nikhil" <nikhil.rao@intel.com>, "Eads, >> Gage" <gage.eads@intel.com>, "hemant.agrawal@nxp.com" >> <hemant.agrawal@nxp.com>, "akhil.goyal@nxp.com" <akhil.goyal@nxp.com>, >> "narayanaprasad.athreya@cavium.com" <narayanaprasad.athreya@cavium.com>, >> "nidadavolu.murthy@cavium.com" <nidadavolu.murthy@cavium.com>, >> "nithin.dabilpuram@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 <abhinandan.gujjar@intel.com> >>> Cc: dev@dpdk.org; Vangati, Narender <narender.vangati@intel.com>; Rao, >>> Nikhil <nikhil.rao@intel.com>; Eads, Gage <gage.eads@intel.com>; >>> 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 <abhinandan.gujjar@intel.com> >>>> To: jerin.jacob@caviumnetworks.com >>>> CC: dev@dpdk.org, narender.vangati@intel.com, Abhinandan Gujjar >>>> <abhinandan.gujjar@intel.com>, Nikhil Rao <nikhil.rao@intel.com>, Gage >>>> Eads <gage.eads@intel.com> >>>> 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 see that there is performance gain in sw side while using ENQ_DEQ mode. But since we already have many modes in the application already, can we make this one with some callback to cryptodev. So the application can call the rte_cryptodev_enqueue_burst() as it is doing, and if the ENQ_DEQ mode is supported by the underneath implementation then, it can register a callback to the implementation that is required in the driver layer itself. In this way, the application will become less complex as compared to the 2 parallel implementations for SW and HW. It will also give more flexibility to the driver implementation as well. -Akhil > >> */ >>> >>>> + * 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 >>> >