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 0C0B6A0350; Tue, 23 Jun 2020 20:38:26 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B1DD81D6CE; Tue, 23 Jun 2020 20:38:24 +0200 (CEST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60084.outbound.protection.outlook.com [40.107.6.84]) by dpdk.org (Postfix) with ESMTP id D54481D6CB for ; Tue, 23 Jun 2020 20:38:22 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EMyxgWt2KUHjg+bL0NPVuDYvE87tUoCyAji6nMYhjFpP3OkllQ73W6mgID4P3BdvIJFr3HKGGBf0W4uFtNz41Vao3gKd40fGryWNuDpKJa3AQCoMQT2FdI1qAbt5/hSSsvcWB7b5Tb72e9vCjjGfzOtJYa34wmR+UzLC2K9+OIWB2mIcADCmClYwUakSwjn2fGLDKAil5/IMsi2nlTdHJTeuMKvJJtHymizpk220M8BdGsg1SIPSmi+gKxXw4DWcVlmiHzkmo1yZdMOHl4MiFD1ViApSWqynC5ePZCeqtG3iLBnfNOwfqWoVX8aXQZsq8mS3aPCi1GMTmf3R5wb3Jg== 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=ybosjBB3tv+eXnt5o7WvrDQ1z2mqxH1Kv22ctgx/eTI=; b=h/NLIrhr9/tJt9c/1IV7tLrCEc04pjCiDIIa+WvSPhOEoFPNebynYsucUT4FTsUQ3XJUHdJadSQ5xcQm3zBZv2H6WnYz7NQYo7WjTvs+fWGwoylDwiBlmnkXhO3+9iAsp9WU60j7qJPXT2tdWNTqF3lBuXE8e/ncr8P9AL05dFV5rWsp66KXn1XHfMeXwoRFMFTo5ksJ4dW8Ax37ZdfEYhBuR1PvmAVVI+8A4S3iUc0V+YmVHqHDDI87swA7wUDG1s47QC3VRAt6KHQmEXcJ6VMXKJ1F3Q8OqzgjG2QD8kLumYvl05vb45rX/Vw+Aa+O8wCmKrgwhtxq521iDrP6Ww== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ybosjBB3tv+eXnt5o7WvrDQ1z2mqxH1Kv22ctgx/eTI=; b=A1s+75onuYTdA4kUZdRevhci/YRDPaLMTCE+OmZWDOGeJb8xtdHocE88naeVljLq8lzzL2xIDb7cWn7RX4dMIftl3ViSoY42qm8d3k81oWakUif8F/Y+gfc3aOB8e2JryGH3Oo0MIwgHYoGjnrNuARcg8dW4qMkSjpBqV0Dfg0Y= Received: from VI1PR04MB3168.eurprd04.prod.outlook.com (2603:10a6:802:6::10) by VI1PR04MB7038.eurprd04.prod.outlook.com (2603:10a6:800:12d::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Tue, 23 Jun 2020 18:38:21 +0000 Received: from VI1PR04MB3168.eurprd04.prod.outlook.com ([fe80::b077:1fe4:d352:b464]) by VI1PR04MB3168.eurprd04.prod.outlook.com ([fe80::b077:1fe4:d352:b464%7]) with mapi id 15.20.3109.027; Tue, 23 Jun 2020 18:38:21 +0000 From: Akhil Goyal To: "Ananyev, Konstantin" , "Coyle, David" , "Doherty, Declan" , "De Lara Guarch, Pablo" , "Trahe, Fiona" , "Zhang, Roy Fan" CC: "dev@dpdk.org" , "thomas@monjalon.net" , "Yigit, Ferruh" , "Ryan, Brendan" , Hemant Agrawal , "anoobj@marvell.com" , "ruifeng.wang@arm.com" , "lironh@marvell.com" , "rnagadheeraj@marvell.com" , "jsrikanth@marvell.com" , Gagandeep Singh , "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: AQHWPmEhogXiOJRyAkOkHGdWxOqfIajQTQ6AgAFdLwCAABcrgIABl22AgBNCtcA= Date: Tue, 23 Jun 2020 18:38:21 +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-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=nxp.com; x-originating-ip: [45.118.167.75] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 0b16362a-b2a3-4014-1699-08d817a49afe x-ms-traffictypediagnostic: VI1PR04MB7038: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04433051BF x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: poXaUA3BK1BTHemIQI0rRcQpbu4bOHEtUd31nqxMWfFgVmGE50i1G6D3mSGwFHCS9yLW4PL6AbLcX2Siyx8O+mftDfzx6wVkYNkcyt1ZXZDlIIVm+rRY5LAoj2X+jz1w4BpI/lhKTf3KwBtw0nhOljBguLD7e1TctFmALIWoXfSr7mSJCBwxO1NXBkrgDizUEmyLqHvHNP185HhNILY85LGOANK4Rc4l2c51C8qPO5K1YbJSG2gwvVczCtA955wl62mm2A+KJlhuklq5PjvVNj5FT2QpikSczTeEPhz+8fy8CqnmRrGeeMX+KSSTr0h0THpzgf5oxZd7yeYkLuiZDUxbIerw/iiokLwscOd1owi2cw3E1XGbFZLo53QXuR5l x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR04MB3168.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(346002)(366004)(396003)(39850400004)(110136005)(76116006)(83380400001)(54906003)(5660300002)(52536014)(44832011)(86362001)(2906002)(15650500001)(26005)(186003)(6506007)(4326008)(7696005)(9686003)(66446008)(71200400001)(64756008)(66946007)(66556008)(66476007)(33656002)(478600001)(7416002)(55016002)(8936002)(316002)(921003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 3Dr3QPbQfvAJPo3fIxlELoCMeEDilYgBq1xPx7t/rhzbJRa2co36nbCZpKKmdp2mOyv6TNcwUChGRMBDWMAIrungYuAuDYrUYJTcFpjyJKTroo+ZdMqWKFkv8awFr34JrdMq6qB1ImsARx0L7mFAWMwd/ehRFWtEDT+v9TYh2CgmNGcjqB/nTxmN13Rzx2qjQFFrgYboILrnCEpdm3Clk4WrFsTyex2OZe3PW58qmlxiarlREG161+XFKC8x755UYDZg+TsRbW+zLNcD+KGKFT/H2Pe3aFT9sHZOoiTWPnaDxLaDnSIMqn9dWb/+SnHNW6h55UhOLjw6v65fg+qWhT6eBbBGQAikfDgCZedwthzHPURYtIWkaB2+d/+k/bMctBseegSm4A/l87za/JuaKdne5wlZ+eu99nukCJiOzHGOeltBNNZlghin/vupgJJkpAObDExGjxQYILEyPBkzWLBgRJS6Gr1/Zlj29K8wAzg= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0b16362a-b2a3-4014-1699-08d817a49afe X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2020 18:38:21.4714 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4e4LYZ1aS+yP8iOikFqvZl8B5ERzQLH3veWolQ7NoONgfZZd23VV/lUMAXrzQl4z2jWogXcby5PqREpUTmdG3w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB7038 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/David, >=20 > Hi David, >=20 > > > > > > > > > > > > > > > > > /** 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 = though > > > 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 comp= iler happy > > > and didn't create a circular dependency. > > > > > > I see... would it be an option to name this struct 'struct rte_sym_do= csis_op > > > and and move actual definition inside > > > lib/librte_cryptodev/rte_crypto_sym.h? > > > > > [DC] It's certainly an option and would work but I don't think it's a g= ood idea to > be putting > > protocol specific structs like this in rte_cryptodev - that's what rte_= security is > for. > > Do you think it would be ok to do this? >=20 > I personally don't see a problem with this. > In fact, as an extra thought - why we can't have docsis xform defined in > lib/librte_cryptodev/rte_crypto_sym.h too, and then just have it as a me= mber > inside struct rte_crypto_sym_xform union? > Then we can have rte_cryptodev_sym_session that supports docsis stuff. Adding DOCSIS alone is not an issue in the cryptodev. The intent of this pa= tchset and=20 Previous RFCs was chaining of two - DOCSIS and CRC which are supposed to be= separate Blocks and we need a way to combine the two and use it in the application. rte_security provides a way to handle such protocols for algo combinations.= =20 However, IMO we do not really need a separate rte_security_docsis_op struct= ure, As it has parameters which are already there in the rte_crypto_sym_op. This= new op Struct is just adding extra bytes which can be avoided if we use sym_op->au= th.data.offset=20 And sym_op->auth.data.length in place of crc offset and crc length. We may just need to add comment in the struct definition about its usage fo= r CRC cases. >=20 > > > > I'd be interested to hear what cryptodev/security maintainers and other= s think > too. > > Akhil/Declan - any thoughts on best approach here?