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 7140DA051B; Wed, 10 Jun 2020 14:03:12 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4A9741BEDD; Wed, 10 Jun 2020 14:03:12 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 938D01BED1 for ; Wed, 10 Jun 2020 14:03:10 +0200 (CEST) IronPort-SDR: ZWOvcj3MCV5rtWQzSU9qWqkBNsJBpHpc+FucwWRSqJoMLAGuXqBiTSJ5WL9xgiIDGRREzSgfqg +5ksBiWpxNlw== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jun 2020 05:03:09 -0700 IronPort-SDR: AE5+5+HT6OW3kbLifsNc0Zzmqfz8QhZeFBrGW0rrUH2+/5T4nSSnsJ53EQv8KK5FRLjOvWjW0F D9s1BhP3Zgfw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,495,1583222400"; d="scan'208";a="349826189" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga001.jf.intel.com with ESMTP; 10 Jun 2020 05:03:08 -0700 Received: from fmsmsx605.amr.corp.intel.com (10.18.126.85) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 10 Jun 2020 05:03:07 -0700 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 10 Jun 2020 05:03:07 -0700 Received: from FMSEDG001.ED.cps.intel.com (10.1.192.133) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Wed, 10 Jun 2020 05:03:07 -0700 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.104) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 10 Jun 2020 05:03:04 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZjKFi/ZQTxz/pVRPAkGePXZZg7x/jB2K7FYBw02o3+qDOgqm2jr2A1jG89rK0ahHyew1aMem01iz0y4uAWukBxIeIU+psNpTh39k+NJ3W1hsDBMbHHFShst5XRX1tTnm07El9+xM8oM5STQUQKl2OFRcqXldux/6gd6udzFsYVaE9g/utHyZpgiVKfO0vBYGh3xImjscX0iKLcK3NYhpym5u7C4jRCcscB/kZ8dVd6GMOWG+uVF9pRQLq09w/gztNek8Ca57wbcSVLo/nzECKc5NErTguHgRXCqsMNCSyxpFSRVXuj5ikxiwhcVO9DrbwUnUB++/A63lvRw61xjiPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=V6hvlZ970glLpfQcLrUf1OJ8/lPoXoseIe81gRctWsw=; b=Twc5256cit5oBdM0v5200d9gvEfCE2Xe+GEDogpuVdnyjNHpz9cYD6PiH/WByQtfsc02+Vru6jlYVmi8yc5wzJkgFgiFqghwvknWbPDGMrwxn7QCm4hK13w9fiJOKodIEddvRLKtOMPdrQhMVKu1z7fEitYrXzO1dMqMXNJ754ohICB73wOvQpGsyehllF8hRyc5DY1s1u0ygvYRfN7Rn03ppr9wNYKuJUJXSLfQxa0zUpcCoSL08KW/9ELOuMO9bhv2grMxGL96ERFoa8/Fz9jn3U1dW1HjB13m2TOto7qFXzzNO4X7gaq4cKRF1QedSQM0+nrW8qRaoOeMYlEbiw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=V6hvlZ970glLpfQcLrUf1OJ8/lPoXoseIe81gRctWsw=; b=H3C9jiVOaLEoMek03u+F4N64uLxwICnl3qWb1RFzfIWiZeOfy3lWfq3FZrSWcRLbvZa+I2pFxRAtkm1Pi6Ya/eHbtxfld3mNDjNKV8zkZ8uzPYaI+knw+C4Jz/DhbyVJhEDyo+olxOu5Aq3DXFhSh/wn1D5tUfjyl3ZmT8JYhio= Received: from MN2PR11MB3550.namprd11.prod.outlook.com (2603:10b6:208:ee::21) by MN2PR11MB4400.namprd11.prod.outlook.com (2603:10b6:208:18c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.20; Wed, 10 Jun 2020 12:03:00 +0000 Received: from MN2PR11MB3550.namprd11.prod.outlook.com ([fe80::8181:d8ec:fef7:532f]) by MN2PR11MB3550.namprd11.prod.outlook.com ([fe80::8181:d8ec:fef7:532f%2]) with mapi id 15.20.3066.023; Wed, 10 Jun 2020 12:03:00 +0000 From: "Coyle, David" To: "Ananyev, Konstantin" , "akhil.goyal@nxp.com" , "Doherty, Declan" , "De Lara Guarch, Pablo" , "Trahe, Fiona" , "Zhang, Roy Fan" CC: "dev@dpdk.org" , "thomas@monjalon.net" , "Yigit, Ferruh" , "Ryan, Brendan" , "hemant.agrawal@nxp.com" , "anoobj@marvell.com" , "ruifeng.wang@arm.com" , "lironh@marvell.com" , "rnagadheeraj@marvell.com" , "jsrikanth@marvell.com" , "G.Singh@nxp.com" , "jianjay.zhou@huawei.com" , "ravi1.kumar@amd.com" , "Richardson, Bruce" , "olivier.matz@6wind.com" , "honnappa.nagarahalli@arm.com" , "stephen@networkplumber.org" , "alexr@mellanox.com" , "jerinj@marvell.com" , "O'loingsigh, Mairtin" Thread-Topic: [dpdk-dev] [PATCH 2/3] cryptodev: add security operation to crypto operation Thread-Index: AQHWPmEdkfXrksBA+U2sUEh94t53P6jQRvZAgAFjRwCAABLg8A== Date: Wed, 10 Jun 2020 12:02:59 +0000 Message-ID: References: <20200410142757.31508-1-david.coyle@intel.com> <20200604151324.50704-1-david.coyle@intel.com> <20200604151324.50704-3-david.coyle@intel.com> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.2.0.6 dlp-product: dlpe-windows authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [192.198.151.182] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 71a16b0c-440d-46c7-957e-08d80d3638b5 x-ms-traffictypediagnostic: MN2PR11MB4400: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0430FA5CB7 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 983xMl9jg3SD0bSiG9eWgvITDHTfPbnInMi4a0eG38OvtCSdf2+1h5iGH3vgQf6ONxeArJgxjjEVxdkTWs0bqxfJ5c50tz50DfvNobpo4meeB1+SL19cITE3uwEq8k7xRJac0uJRgvgCnC8MiEX9Cv5XKHnHBCbLLvdQk6CFuxbxe3ASpdZcVllA+BjmIFW994WQFIRAUo0JVMHv5sOe8tyfV5n9LR4ihmOokGnLG1M/mIZk8l1dLTNH1ZpYX29ItxOwgsyiHVYh4BYQS2+zG/nIvtEbm7L8kJJut/5JomrG94xnWqUbnyEjJpkHlJCby5nDELiC7UdcNvbtlqBQC4bocP6NrUgyU/wVVya01LtZ4/uRhdDdTKyJ/tKu7I83 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3550.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(346002)(376002)(366004)(136003)(396003)(39860400002)(7416002)(66476007)(76116006)(316002)(64756008)(66946007)(6636002)(66446008)(5660300002)(107886003)(71200400001)(52536014)(66556008)(33656002)(7696005)(55016002)(2906002)(83380400001)(478600001)(6506007)(15650500001)(8936002)(26005)(86362001)(110136005)(4326008)(54906003)(186003)(9686003)(921003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: P7ulEVkeUyqEXhDovRJ4rm+5+J0q10SshW8Rrr5a9f4s8xF8zMF/wRaOG+FZb9ydlnuW4Kq28cl/xe2eYwLzlfhPgBMBxS3BstTNBdHs6kclZqMCrIwwbjj4G6DF8op1U/+Rx1R6I5wlP4KEG9yUy9lO87WCSOCO3VTZ3tR9ZJWy//gTrYCIZqY/K5gFCvZ5lnuAFl7rxojdhc2sP4Fid8MaIlPBMpWkgSN93B9GYUIwnn0vRqcHJfKNfbyzTp0SeZQ8YeUofu7BRgG36NvxeuCEiE2DHRcfXRPNiLgKaNQ7VEwgiwj8pcJqwVzZLjovh7y8jpMJKtXv07yguz76PbwZ+UuQ2u5ImN1YH3YikyvxL6Tp+r44VBzOXsdCGetNApcI2KkGd7JBwdD9E/mgzFD4xxL8vHxQ4XKtcGyQijQIOmUoA+NYXq8HDwDAV7erDvdHeLzw3gpBYtz4LaYkL23H40gL9M2dKhDbC2+PwmRJr8V9/OsNKZdDZRAyiD77 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 71a16b0c-440d-46c7-957e-08d80d3638b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2020 12:02:59.8097 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: x1/LmlqlucyawjDcq2oYAf6RNxkqnn9TxjrFs9wxuS69ViQLVnZgut7xGodK6fhtIinDlHcl0/uaUjGde49itQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4400 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH 2/3] cryptodev: add security operation to crypto operation 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" Hi Konstantin, > > > > > > > > > > > /** Status of crypto operation */ @@ -121,6 +123,13 @@ struct > > > > rte_crypto_op { > > > > struct rte_crypto_asym_op asym[0]; > > > > /**< Asymmetric operation parameters */ > > > > > > > > +#ifdef RTE_LIBRTE_SECURITY > > > > + uint8_t security[0]; > > > > + /**< Security operation parameters > > > > + * - Must be accessed through a rte_security_op pointer > > > > + */ > > > > +#endif > > > > + > > > > }; /**< operation specific parameters */ }; > > > > > > Is there any point to have this extra level of indirection? > > > Might be simply: > > > > > > enum rte_crypto_op_type { > > > .... > > > + RTE_CRYPTO_OP_TYPE_SEC_DOCSIS, > > > }; > > > ... > > > struct rte_crypto_op { > > > .... > > > __extension__ > > > union { > > > struct rte_crypto_sym_op sym[0]; > > > /**< Symmetric operation parameters */ > > > > > > struct rte_crypto_asym_op asym[0]; > > > /**< Asymmetric operation parameters */ > > > > > > + struct rte_security_docsis_op docsis[0]; > > > > > > }; /**< operation specific parameters */ > > > > > > ? > > [DC] This was to allow some form of extensibility and not to limit this= to just > DOCSIS. > > If it's felt that having the extra level of indirection is overkill, it= can be easily > changed. > > > > However, we cannot include a struct of type 'struct > > rte_security_docsis_op' (or 'struct rte_security_op') directly here, > > without creating nasty circular dependency of includes between > rte_cryptodev and rte_security. > > > > I had tried defining an opaque version 'struct rte_security_op' (i.e. > > no fields within the struct) here in rte_crypto.h, but the compiler > > complained that it couldn't determine the size of the struct, even thou= gh > it's a zero length array. > > > > That is why I had to use the uint8_t in 'uint8_t security[0];' - I > > don't like this, but I couldn't find another way that kept the compiler= happy > and didn't create a circular dependency. >=20 > I see... would it be an option to name this struct 'struct rte_sym_docsis= _op > and and move actual definition inside > lib/librte_cryptodev/rte_crypto_sym.h? >=20 [DC] It's certainly an option and would work but I don't think it's a good = idea to be putting protocol specific structs like this in rte_cryptodev - that's what rte_secu= rity is for. Do you think it would be ok to do this? I'd be interested to hear what cryptodev/security maintainers and others th= ink too. Akhil/Declan - any thoughts on best approach here? >=20