From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0086.outbound.protection.outlook.com [104.47.32.86]) by dpdk.org (Postfix) with ESMTP id 43B1D2C66 for ; Tue, 20 Feb 2018 15:00:03 +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=ZUoUamRYeU5k/pPJOXW+BHys9s6t+9rE4m4IFFDXoco=; b=PUrdFU8jJSn34oz84vvDsiFeuHVKvkeIgQq6FA3qHOY8qvSHnn1IH3v4p1KrC+ouozRXJ7eFBdHefTPRsx0RBMDONPdwPwlDwmap0jHtfLhpASRv9kNkbpldeuwrO2B3g75jTPsM+tmKqZa/QiSeHVjt1CkvVN5MIkLchMCu7Fs= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; Received: from jerin (111.93.218.67) by SN2PR07MB2526.namprd07.prod.outlook.com (2603:10b6:804:6::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Tue, 20 Feb 2018 13:59:57 +0000 Date: Tue, 20 Feb 2018 19:29:21 +0530 From: Jerin Jacob 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" Message-ID: <20180220135920.GA23970@jerin> References: <1516013630-146114-1-git-send-email-abhinandan.gujjar@intel.com> <20180216193348.GA8882@jerin> <5612CB344B05EE4F95FC5B729939F7807069B737@PGSMSX102.gar.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5612CB344B05EE4F95FC5B729939F7807069B737@PGSMSX102.gar.corp.intel.com> User-Agent: Mutt/1.9.3 (2018-01-21) X-Originating-IP: [111.93.218.67] X-ClientProxiedBy: BM1PR0101CA0070.INDPRD01.PROD.OUTLOOK.COM (2603:1096:b00:19::32) To SN2PR07MB2526.namprd07.prod.outlook.com (2603:10b6:804:6::26) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d8c5640f-8839-4b5f-fdfc-08d5786a3bf8 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:SN2PR07MB2526; X-Microsoft-Exchange-Diagnostics: 1; SN2PR07MB2526; 3:qpaoD+3Zrx/RNAHNFPBNkhpcS0ztp/nTbAC6ywW5YtUjnDQBcUb/Mp4T0gy1q0SgIKWKus2LaYHg3qrCZ4a3lW4K57TXI/iIi9nzkCW2JncitfliykCH5PKJszQmxeMlY7QBS8FchbD5TkU+Jljda6z71VaC2HqNau7tLl7uxJXoi5C5Rh79tOyf+E3DTStRULVkz198HPBnB1yhVHpq2m9Sa0zq+S/YiktCFcZsyRAUBZ8DKyItk+HCtEJVP1e0; 25:YdSubV49uKt6ow1JIVMaR3lTAtzJChUhyquvR6PfDM5AFHlaMBu5asspVJ9vL4yAl7cB+D5Xq1hMuEYoiIU61nMWpzWDAuTBL5TnnrK1n+GZGF2yqNuWSAGZCyiqj+pYoLJvtRhTzCbQklYzwvokJ2meTksOBjQxT4sVVFLpKsA7v4LooXTvvE/pE8D6Vk8BTL71FpJoVbxLYC/2l4KKZtKdIkVxgs4tbh7Q+A+kUSt/uRP1DSP1FMBgGCFncTnAOwezRsg8Qd9KEbymmlxrxi+x0lFqScLJaos1sveFoXwZDmLs42glTQwcJwVKN0ynHRji84X2CUGNrEcZqbq7Rw==; 31:w19PwSqTHHGd6CkIrFQiS1BnzRJesigOQSb1s3hbeiDg+ozjAGqBInhDtetJvbyIoiZXHTRENpg0bnAJH2zPqvcSMepdzt894J16nHHVv70jxnWQFDofR5CUs0wZOsLUQUqa6JelhFL+VlVyiL41V5qFxr51OYINQxi3wj6QzUNDOC9PKbDJGzKa3W/yd+bgaOjuq0P5OxLsDgi31qnKNTHZxFtQxd+Uir86gHbcQF0= X-MS-TrafficTypeDiagnostic: SN2PR07MB2526: X-Microsoft-Exchange-Diagnostics: 1; SN2PR07MB2526; 20:/P78B7qN/q8qz1FQWdE8QMrtULlqhnxnOnXL3N+AfTxoZc5JQBQ9NrDlisCfTSU+rkqiF7Na5WHdKAGYQsMlQc1e4LvxXAE/fRIPMnDZLrIrPszWQWcQChZN342rituhGZ5qr1C1Zq8PiG+ALRHV1seLPitRsUsaXACIwI1lmwoylLJxIXgnaw4g83FeNFrK0ysJ56IBH1kCcOPacO1VU/Uiie261KJ0zXwmwrqy7+Huy76P5ObXLt9lbA24OBl2U9ilStTLQCIM0bB12KbKtRn3Rw6kZSPDAMDrgNMq96GZsTEiuTzgc4Jvjqyr7b3DuClnH21q+AlVjRGG75KAM8jfqS/w6x8Qrm1eQAmH8jWQ9A/W1HXJgbFP0XRgGgpNeJzogtq3w3Xf3bfS+4XZZw52kX4JRbQrRrgzPlMUsTiUgaPgS8TTHicJE9OVCIf8zx3YHTcVNDmPJG+8pRQMsJuN3WSm9tjipqtex7/y5wn1o9+JCIMU69qIixuAUPmHB6MJ9vHPLnGqWtYarbPCIenJBgp/TDC9Dez3NuHRjN1GI1zPnKg2FhgarDsy6x+bq1M65FcvwTZ+0ukJ51Zw1046I8L5QVoldN2Idf40z/8= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(185117386973197)(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001056)(6040501)(2401047)(5005006)(8121501046)(3002001)(3231101)(944501161)(93006095)(10201501046)(6041288)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:SN2PR07MB2526; BCL:0; PCL:0; RULEID:; SRVR:SN2PR07MB2526; X-Microsoft-Exchange-Diagnostics: 1; SN2PR07MB2526; 4:aPo+b8v3LIbHNU+jV3iO+w8TU3yo+DycVSOaPYLKmPGDZSrs8m0rTjROSNQaBNKbN3hjErw5ufaX8S9sauSHbnx/W0qauLF7L8zv0NlROIE2TBQ5bXeXpLW+4b4dffMtocQQEO/3zCjn1pCDNsNCLOL1PSBsoJjEFxrC5SseXUCslCP747YPGEqHS6jtlhxTStz17bKCY59keDbtW2P4whfXC/dvWOS5XZqcyn4H5bI/o/1I/VnaIWnH5nwC3fHiURNm1tKAXfNo0EDuQ0ZXksq6EABSSYxp+cC4pNjeNWyiixBzPOE4pJ1TXFaNPXOfSW6Bv3Z/EMqAEqr/F3om9CysW1JsgJtOlZ9ZWgr+ECU= X-Forefront-PRVS: 05891FB07F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(396003)(376002)(346002)(39860400002)(39380400002)(366004)(199004)(189003)(51914003)(13464003)(58126008)(59450400001)(6916009)(33896004)(47776003)(5660300001)(316002)(25786009)(52116002)(16586007)(53936002)(76176011)(1076002)(2906002)(8936002)(386003)(53546011)(6666003)(9686003)(42882006)(50466002)(2950100002)(8656006)(6246003)(8676002)(106356001)(33656002)(97736004)(83506002)(6496006)(54906003)(81166006)(16526019)(81156014)(3846002)(5009440100003)(229853002)(6116002)(7736002)(105586002)(66066001)(33716001)(68736007)(72206003)(478600001)(4326008)(186003)(305945005)(107886003)(23726003)(55016002)(26005)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR07MB2526; 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; SN2PR07MB2526; 23:Oq6eRUynXHyGu9+0z+usoOmDUCegGOoVwQpGJtxuu?= =?us-ascii?Q?aVZg/nzxLSrT+3XtN0kGXQxlk0X3oZGjGX2jiJ5jzJ7mahdFLZm9eJW9zq7l?= =?us-ascii?Q?7lxRsgcgEd6+cqK9snrErD9k2Himuexliot8UqYnz/6ezjkVEZ+v59F+c7wJ?= =?us-ascii?Q?UIfcM7jv3sGG0Ux3Oa4grJeqpqVGluEY0jrihL07uzSUQvOokJW7H8sjH2qo?= =?us-ascii?Q?S5+gOxpDDyF/ZS2TDW1PS8RHNkXEpr+vO0a51sfyIQ6wj9ijSHKwY9IpH824?= =?us-ascii?Q?dExpfArAZyOzP/0ZQhzCLmvnEbHOvd+zALh9wybOW/GSdDTszFPHLF1YEyhZ?= =?us-ascii?Q?1j5itZJhSh5M+UXserLsKzdm/k6+4x9+eKu84fcQSueD32AFwr0MSgPoNb4K?= =?us-ascii?Q?VG64NzapCbOSm4TR/VPglxb4AmnMXRZvvDZVWf16P5L+AdJwtVl1kor5jUs1?= =?us-ascii?Q?wO2/fOG3cULDmWXQIG6LVZDlyCpMI5t1JJNrYjzVXRwSpdpQfA1NoNLSeSYI?= =?us-ascii?Q?vlyEwVAEfdXyp/XxrugudhTN3I8nGhV2ImhiiJP0aPKU5RZ1LVSfrgYBRrmi?= =?us-ascii?Q?Dw/MfDDKIL1jARelanDz+aEFANBy8KxOOdbVpcEJ/kfR6cNVFqjxPm7koGa6?= =?us-ascii?Q?3uwv6phUhGgVNmv+B1FoqRGEJDSWE+32IhZMI+p1ruoQVD11/LHAA2205Lef?= =?us-ascii?Q?VeI3pCCAvLDCuuDyOkSYVbFWiz0yZnvPV8LRoU1Yso+2WrAtaSCGiQduDYfC?= =?us-ascii?Q?1pXghQeTpXBrG3NibJfsykD54bg5o5lMVGxM4ioMDEt/RUROMoLERbD0BXm+?= =?us-ascii?Q?1FD+g2DFklRpJgDaET7nnZAbkb3Hqr4pbE/TgYKR4btBP14fEuiT8paiP3FP?= =?us-ascii?Q?V9Szq6DE1s9SmoUW/hLTMFY18eT8gUwGaTJcpAGqULs+dJP2SAZkAqj3o+Im?= =?us-ascii?Q?2lnGWE3oQ+243GttE0H9MjyI00mpWmws4PIDpZLuUgvAwouCUR5m4xDl9q+s?= =?us-ascii?Q?7HzHLAeorKyVgkOYPsvX4brwnFldDOUVrMIGQIWZBdf83oHY2CXGAquwRqvi?= =?us-ascii?Q?CHw1zdcoCSDH/E5KJX3K0HMr38FuR0TjthCPtNHJjC3cUCuffgBGuUhqoUwA?= =?us-ascii?Q?KVeR+1YDn0QLwzDzR56mBNQckdcW/HqQKkmHurourbtJpydglzbCgMUAICCT?= =?us-ascii?Q?1DgRu4W6rhgnyD0NoUWVbPGia03yQ9M4rpQVWSzeHY1pAgxvqZN1f5kQrzc+?= =?us-ascii?Q?l9y4TxkI7x9SSN8XNeO9AR6nDUSVz5TUdF+th/E+HNpZzxzR658S9Q7ub8Uo?= =?us-ascii?Q?CMxzki9iuhEcCNuRIz6hl+qk5cVH45LUWtSE/9ly6pR8meU+VLGf5xpUNwrl?= =?us-ascii?Q?5zbw5EAPL/yefZ21x7Ueg9B9TY7/j1sRLATJXJpCO/9tAkFp7wjp0+CXCRGt?= =?us-ascii?Q?PSEk5E8TahHVqjPIDeM+L8n2AMY+j0=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR07MB2526; 6:A/IxPeqB58vH2vtlHcdOvOdd/JmkHZ83vyUYSvM9PSsmaF49LSvE1WNsz/GlZMtWRZF9s6wprOm65t+aLOR2ZUJSTY1ipB/5ZNkblEW6wXM0CzjGyWfx9Rj7JY6ZPbocOyJApMaiHQiVkKZSJnk4MCTwiYACE/i7J0E8WoNPvFwZaCGI80iJeeVmlwUmc0IVePGYbLyhIcOu30nkTvJ3l0mb3esaB8Milx0WPvm2fgpuhBHEhzJZiVxj7FYO/ztT0APVAyacXJDdpx7wg2FP2wh1ChEvVh2DjU8zeJEhaV5ajRZMx0P2gKzW69iFXcd9fz8nMenGjS/VcXs+yw4qySbGqnYfig9RkPQYp9KwrSo=; 5:K6c1l2OjzhspgC1kkSdsRWSmv9okIaohl/byYyAqeUxTFBdaldsButG9pfJqIV2fTKk3og64ghMZg56sxqeKWgwik9gE+X59IMV333wE/I2nDgTlGmlY+ALZx8iSk6Evglz3veeTclYuMROzsjWorEy79Z894IdyxrRfV10nW+k=; 24:Xma9Y9iSS9HYFiplLegS8ry+2rMSxLmWtGpLZDom7ttZfMQbCL1on7jwtezSeG/fFp8vTKsoUlAbGOXT7EzX6wZFcF5fFv9pUxLrVVkc0D4=; 7:N7RkE2VrwoZSfoenDFnVnSJAp/y7jjUysFxD20WnJL3QlGwptSQZeleAqYW3lxV6hbgd4WfklKGwquJWz5dGGbzyjX5txdoDjOBIujVj1UuPSQJ5zdy768293XVYYMNU3IYz/4QHKIvSEIPY3dpnu4P9vsgsxLxFmx6u9FucULZwgOR0sKttrWwq5ihaatQ2fsnvDpPcwnQjeJQ9PNJ0/2t1+yCJ047kKP0LBC3cTUI8es9WYO8qobhEzX7Yh+2n SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Feb 2018 13:59:57.8958 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d8c5640f-8839-4b5f-fdfc-08d5786a3bf8 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR07MB2526 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: Tue, 20 Feb 2018 14:00:03 -0000 -----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? > */ > > > > > + * 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 > >