From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id CA2A7A04B3; Tue, 28 Jan 2020 18:27:59 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5ECB51D579; Tue, 28 Jan 2020 18:27:58 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 3DFDD1D56E for ; Tue, 28 Jan 2020 18:27:56 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jan 2020 09:27:55 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,374,1574150400"; d="scan'208";a="229347042" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.61]) ([10.237.221.61]) by orsmga003.jf.intel.com with ESMTP; 28 Jan 2020 09:27:51 -0800 To: Anoob Joseph , Akhil Goyal , Jerin Jacob Cc: Declan Doherty , Thomas Monjalon , Jerin Jacob Kollanukkaran , Narayana Prasad Raju Athreya , Kiran Kumar Kokkilagadda , Nithin Kumar Dabilpuram , Pavan Nikhilesh Bhagavatula , Ankur Dwivedi , Archana Muniganti , Tejasree Kondoj , Vamsi Krishna Attunuru , Lukas Bartosik , dpdk-dev References: <1575806094-28391-1-git-send-email-anoobj@marvell.com> <1579344553-11428-1-git-send-email-anoobj@marvell.com> From: Ferruh Yigit Autocrypt: addr=ferruh.yigit@intel.com; prefer-encrypt=mutual; keydata= mQINBFXZCFABEADCujshBOAaqPZpwShdkzkyGpJ15lmxiSr3jVMqOtQS/sB3FYLT0/d3+bvy qbL9YnlbPyRvZfnP3pXiKwkRoR1RJwEo2BOf6hxdzTmLRtGtwWzI9MwrUPj6n/ldiD58VAGQ +iR1I/z9UBUN/ZMksElA2D7Jgg7vZ78iKwNnd+vLBD6I61kVrZ45Vjo3r+pPOByUBXOUlxp9 GWEKKIrJ4eogqkVNSixN16VYK7xR+5OUkBYUO+sE6etSxCr7BahMPKxH+XPlZZjKrxciaWQb +dElz3Ab4Opl+ZT/bK2huX+W+NJBEBVzjTkhjSTjcyRdxvS1gwWRuXqAml/sh+KQjPV1PPHF YK5LcqLkle+OKTCa82OvUb7cr+ALxATIZXQkgmn+zFT8UzSS3aiBBohg3BtbTIWy51jNlYdy ezUZ4UxKSsFuUTPt+JjHQBvF7WKbmNGS3fCid5Iag4tWOfZoqiCNzxApkVugltxoc6rG2TyX CmI2rP0mQ0GOsGXA3+3c1MCdQFzdIn/5tLBZyKy4F54UFo35eOX8/g7OaE+xrgY/4bZjpxC1 1pd66AAtKb3aNXpHvIfkVV6NYloo52H+FUE5ZDPNCGD0/btFGPWmWRmkPybzColTy7fmPaGz cBcEEqHK4T0aY4UJmE7Ylvg255Kz7s6wGZe6IR3N0cKNv++O7QARAQABtCVGZXJydWggWWln aXQgPGZlcnJ1aC55aWdpdEBpbnRlbC5jb20+iQJUBBMBCgA+AhsDAh4BAheABQsJCAcDBRUK CQgLBRYCAwEAFiEE0jZTh0IuwoTjmYHH+TPrQ98TYR8FAl1meboFCQlupOoACgkQ+TPrQ98T YR9ACBAAv2tomhyxY0Tp9Up7mNGLfEdBu/7joB/vIdqMRv63ojkwr9orQq5V16V/25+JEAD0 60cKodBDM6HdUvqLHatS8fooWRueSXHKYwJ3vxyB2tWDyZrLzLI1jxEvunGodoIzUOtum0Ce gPynnfQCelXBja0BwLXJMplM6TY1wXX22ap0ZViC0m714U5U4LQpzjabtFtjT8qOUR6L7hfy YQ72PBuktGb00UR/N5UrR6GqB0x4W41aZBHXfUQnvWIMmmCrRUJX36hOTYBzh+x86ULgg7H2 1499tA4o6rvE13FiGccplBNWCAIroAe/G11rdoN5NBgYVXu++38gTa/MBmIt6zRi6ch15oLA Ln2vHOdqhrgDuxjhMpG2bpNE36DG/V9WWyWdIRlz3NYPCDM/S3anbHlhjStXHOz1uHOnerXM 1jEjcsvmj1vSyYoQMyRcRJmBZLrekvgZeh7nJzbPHxtth8M7AoqiZ/o/BpYU+0xZ+J5/szWZ aYxxmIRu5ejFf+Wn9s5eXNHmyqxBidpCWvcbKYDBnkw2+Y9E5YTpL0mS0dCCOlrO7gca27ux ybtbj84aaW1g0CfIlUnOtHgMCmz6zPXThb+A8H8j3O6qmPoVqT3qnq3Uhy6GOoH8Fdu2Vchh TWiF5yo+pvUagQP6LpslffufSnu+RKAagkj7/RSuZV25Ag0EV9ZMvgEQAKc0Db17xNqtSwEv mfp4tkddwW9XA0tWWKtY4KUdd/jijYqc3fDD54ESYpV8QWj0xK4YM0dLxnDU2IYxjEshSB1T qAatVWz9WtBYvzalsyTqMKP3w34FciuL7orXP4AibPtrHuIXWQOBECcVZTTOdZYGAzaYzxiA ONzF9eTiwIqe9/oaOjTwTLnOarHt16QApTYQSnxDUQljeNvKYt1lZE/gAUUxNLWsYyTT+22/ vU0GDUahsJxs1+f1yEr+OGrFiEAmqrzpF0lCS3f/3HVTU6rS9cK3glVUeaTF4+1SK5ZNO35p iVQCwphmxa+dwTG/DvvHYCtgOZorTJ+OHfvCnSVjsM4kcXGjJPy3JZmUtyL9UxEbYlrffGPQ I3gLXIGD5AN5XdAXFCjjaID/KR1c9RHd7Oaw0Pdcq9UtMLgM1vdX8RlDuMGPrj5sQrRVbgYH fVU/TQCk1C9KhzOwg4Ap2T3tE1umY/DqrXQgsgH71PXFucVjOyHMYXXugLT8YQ0gcBPHy9mZ qw5mgOI5lCl6d4uCcUT0l/OEtPG/rA1lxz8ctdFBVOQOxCvwRG2QCgcJ/UTn5vlivul+cThi 6ERPvjqjblLncQtRg8izj2qgmwQkvfj+h7Ex88bI8iWtu5+I3K3LmNz/UxHBSWEmUnkg4fJl Rr7oItHsZ0ia6wWQ8lQnABEBAAGJAjwEGAEKACYCGwwWIQTSNlOHQi7ChOOZgcf5M+tD3xNh HwUCXWZ5wAUJB3FgggAKCRD5M+tD3xNhH2O+D/9OEz62YuJQLuIuOfL67eFTIB5/1+0j8Tsu o2psca1PUQ61SZJZOMl6VwNxpdvEaolVdrpnSxUF31kPEvR0Igy8HysQ11pj8AcgH0a9FrvU /8k2Roccd2ZIdpNLkirGFZR7LtRw41Kt1Jg+lafI0efkiHKMT/6D/P1EUp1RxOBNtWGV2hrd 0Yg9ds+VMphHHU69fDH02SwgpvXwG8Qm14Zi5WQ66R4CtTkHuYtA63sS17vMl8fDuTCtvfPF HzvdJLIhDYN3Mm1oMjKLlq4PUdYh68Fiwm+boJoBUFGuregJFlO3hM7uHBDhSEnXQr5mqpPM 6R/7Q5BjAxrwVBisH0yQGjsWlnysRWNfExAE2sRePSl0or9q19ddkRYltl6X4FDUXy2DTXa9 a+Fw4e1EvmcF3PjmTYs9IE3Vc64CRQXkhujcN4ZZh5lvOpU8WgyDxFq7bavFnSS6kx7Tk29/ wNJBp+cf9qsQxLbqhW5kfORuZGecus0TLcmpZEFKKjTJBK9gELRBB/zoN3j41hlEl7uTUXTI JQFLhpsFlEdKLujyvT/aCwP3XWT+B2uZDKrMAElF6ltpTxI53JYi22WO7NH7MR16Fhi4R6vh FHNBOkiAhUpoXRZXaCR6+X4qwA8CwHGqHRBfYFSU/Ulq1ZLR+S3hNj2mbnSx0lBs1eEqe2vh cA== Message-ID: <6f0f2513-7d4d-07b1-1c93-6457eeecd4c8@intel.com> Date: Tue, 28 Jan 2020 17:27:50 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v2 00/15] add OCTEONTX2 inline IPsec support 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 1/27/2020 2:54 PM, Anoob Joseph wrote: > Hi Jerin, Akhil, > > Let me summarize the design changes from the discussions below. > > Currently, drivers/crypto/octeontx2/otx2_security.c defines all security ctx ops for the ethdev (idea was to add all crypto security ctx for lookaside also there). That will be moved to drivers/net/octeontx2 as is. The routines which are doing qp_add & qp_remove would be moved to common (discussed below). Otherwise, the rest should remain as is. If Jerin/Akhil wants further isolation, please do share specifics. Almost all functions in otx2_security.c is dereferencing 'rte_eth_dev'. So having (void *) will not help. > > The functions in otx2_security.c is calling inline functions in otx2_ipsec_fp.h (which has lower level implementations of session create etc). This will remain as is in drivers/crypto/octeontx2 but would be called from drivers/net/octeontx2/otx2_security.c. > > We will need to include otx2_cryptodev_qp.h (internal header in drivers/crypto/octeontx2) since the crypto queue pair is required for outbound processing. Since otx2_cryptodev_qp.h has dependency on rte_cryptodev.h, the ethdev file will have dependency on rte_cryptodev.h. > > I want all the maintainers (Akhil, Jerin & Ferruh) to ack the above behavior so that I can proceed with the restructuring. (Currently issue is rte_ethdev.h getting included in a cryptodev PMD file. The case we are proposing is the exact mirror of that) > > Currently, the cryptodev has to do qp-eth port mapping and save it somewhere for eth dev to use during security session create. This will have to be saved in drivers/common/octeontx2. > > @Ferruh, do you agree with the suggestions here? With the proposed changes, parts of the patches would go into ethdev space (for reviews and merge), and the rest would be in crypto space. Hi Anoob, It is OK to move the 'rte_security_ops' to net driver, as far as I can see there is no way to isolate ethdev and cryptodev completely, at least having one way ethdev->crypto dependency is better. Not sure about using inline functions though, existing solution to use common/x looks OK to me. > > Thanks, > Anoob > >> -----Original Message----- >> From: Akhil Goyal >> Sent: Monday, January 27, 2020 5:18 PM >> To: Jerin Jacob >> Cc: Anoob Joseph ; Declan Doherty >> ; Thomas Monjalon ; Jerin >> Jacob Kollanukkaran ; Narayana Prasad Raju Athreya >> ; Kiran Kumar Kokkilagadda >> ; Nithin Kumar Dabilpuram >> ; Pavan Nikhilesh Bhagavatula >> ; Ankur Dwivedi ; >> Archana Muniganti ; Tejasree Kondoj >> ; Vamsi Krishna Attunuru ; >> Lukas Bartosik ; dpdk-dev >> Subject: [EXT] RE: [dpdk-dev] [PATCH v2 00/15] add OCTEONTX2 inline IPsec >> support >> >> External Email >> >> ---------------------------------------------------------------------- >> Hi Jerin, >> >>> >>> On Mon, Jan 27, 2020 at 4:10 PM Akhil Goyal wrote: >>>> >>>> >>>>> >>>>> On Wed, Jan 22, 2020 at 6:26 PM Akhil Goyal >> wrote: >>>>>> >>>>>>>>> >>>>>>>>> Hi Jerin, >>>>>>>>> >>>>>>>>> Will do the suggested change (RX/rx-> Rx & TX/tx->Tx). Do >>>>>>>>> you want >>> me >>>>>>>>> to trim the headline as well? >>>>>>>>> >>>>>>>> >>>>>>>> Hi Anoob, >>>>>>>> >>>>>>>>> @Akhil, did you get a chance to review the series? Do you >>>>>>>>> have any comments on the patches? >>>>>>>>> >>>>>>>> >>>>>>>> You are adding inline ipsec support to ethernet device and >>>>>>>> not a crypto device. >>>>>>>> These patches should not be part of crypto PMD. There will >>>>>>>> be cyclic dependency Between ethernet device and crypto >>>>>>>> device which can be >>>>> easily >>>>>>>> avoided. >>>>>>> >>>>>>> [Anoob] We have plans to use lookaside protocol to handle the >> "fallback" >>>>>>> session. And that involves session sharing between inline and >>>>>>> lookaside >>>>> protocol >>>>>>> offloads. Also, though the feature is exposed as a feature of >>>>>>> ethdev, on >>> our >>>>>>> platform, it's the crypto block which primarily implements the feature. >>> And >>>>> so, if >>>>>>> the code is moved to ethdev dir, there would be lot of code duplication. >>> The >>>>>>> idea is to have all security related code in one place. >>>>>>> >>>>>>> Also, the PMDs don't have any calls to each other. The >>>>>>> communication >>>>> between >>>>>>> the two happens via common. The crypto dev PMD will register >>>>>>> the >>> required >>>>>>> security ops to a common structure and ethdev would get it from there. >>> So >>>>> there >>>>>>> won't be an issue of build dependency. >>>>>>> >>>>>> >>>>>> - The code that need to be duplicated can be moved to >>>>>> drivers/common/ >>>>> >>>>> I would like to keep the common code that is common to all the >>> coprocessors. >>>>> >>>>> Moreover, there are logistic issues in that case where >>>>> a) drivers/common/octeontx2/ going through master repo. So we will >>>>> be creating unnecessary dependency with that 'master' tree. >>>>> b) crypto and ethdev work is done by different teams so we would >>>>> like to make responsibly clear wrt the review and ownership. >>>> >>>> I can agree upon that the code shall not be placed in the >>>> common/octeontx2, But you can have a header file in >>>> crypto/octeontx2/ which has some inline >>> functions >>>> Which can be called from the ethernet as well as crypto device for >>>> inline proto And lookaside cases respectively. I think with that the >>>> maintainability would >>> not >>>> be an issue. >>>> >>>> IMO, following approach can be looked upon and may be cleaner >>>> - define security ctx and its ops in net/octeontx2.c or >>>> net/octeontx2_security.c These are all control path and should not be any >> issue. >>>> >>>> - define crypto specific code (inline functions) in >>>> crypto/octeontx2_security.h Which can be called for both inline protocol as >> well as lookaside proto case. >>> >>> One problem with such an approach is we need to have fat inline functions. >>> In some case, those inline functions to needs accessing the >>> array/driver specific symbols in another driver namespace then those >>> array needs to be exported in map file and hence the build dependency >>> comes. >> >> How many such symbols are there. I don’t they will be many. Can they be Passed >> as argument in the APIs to avoid build dependencies. >> >>> >>> >>>> >>>> - for data path you can have the processing as is. I hope all >>>> dependencies can Be dealt with as the code will be there in crypto >>>> driver for all the mapping of Event and crypto queues. >>>> >>>> - all APIs which are common for ethernet device and crypto device in >>>> octeontx2_security.h should not prefix eth as is the case in current APIs. >>> >>> If I understand it correctly, You have a concern in having the >>> *rte_eth* symbols in driver/crypto/octeontx2? >>> If so, we can check what can be done. Let us know the exact your >>> concern in managing the code in this model? >> >> Yes, rte_eth* symbols should not be there in crypto driver. >> Because crypto driver is not leveraging any ethernet functionality, It is the other >> way, ethernet device is using the crypto functionality/ Structs etc for supporting >> inline IPSEC. >> >> Also, the security ctx should be part of ethdev and its ops should be Defined in >> ethernet device which may call some inline APIs placed in >> Drivers/crypto/octeontx2/ >> >>> >>>> >>>> I hope this will clear the ugliness of the code. >>> >>> It is relative, I think, having fat inline functions and accessing >>> both drivers is ugly. >> >> Breaking the way an API need to be defined and used is even more uglier. >> IMO, having fat inline functions will act as external library functions which Are >> independent of the device which is calling it. >> Something similar to drivers/common/dpaax/caamflib/. >> >> My original suggestion was to put it in common, but I am ok, if you want that In >> the crypto driver. I agree with the decision that all crypto/ipsec related stuff >> Should be there under drivers/crypto if it is getting used from both the net and >> Crypto driver. But atleast the API definitions should be there where it should be. >> >> >>> >>>>> >>>>> I would like to keep the security/crypto-related code to >>>>> driver/crypto and hook to driver/net/octeontx2 with required >>>>> functionalities over the driver/common using a few function >>>>> pointers to remove the cyclic build dependency. >>>>> >>>>> Considering there is no cyclic build and shared library dependency >>>>> now, Can we make forward progress with the existing scheme? >>>>> >>>>>> - You may not need to include rte_ethdev.h inside drivers/crypto >>>>>> - otx2_sec_eth_ctx_create should be part of ethdev and you would >>>>>> need >>>>> similar API >>>>>> for crypto device as well when you would support the fallback >>>>>> session >>> support. >>>>>> So that would go in crypto. Session creation code may be common >>>>>> and can >>> go >>>>>> in drivers/common. >>>>>> - You would have separate security_ctx for both eth device and >>>>>> crypto >>> device >>>>> and that should >>>>>> In net device and crypto device separately. Similarly >>>>>> security->ops should >>> be >>>>> different in both of them. >>>>>> However if they may have same session creation code and that can >>>>>> go in >>>>> common. >>>>>> >>>>