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 A47DDA00C5; Thu, 11 Jun 2020 16:01:22 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 252E5F12; Thu, 11 Jun 2020 16:01:22 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 0452EF04 for ; Thu, 11 Jun 2020 16:01:19 +0200 (CEST) IronPort-SDR: ZYVAFxEzVaVnZvfnjasnhwROVY87ilFZxpXpxc8HpzVirEfyXMb/bsAmmrsudVVxa27XPT8zUP rXrJHpnfT0oQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jun 2020 07:01:18 -0700 IronPort-SDR: l945lB19qTfpPvaWc2/T2VC74vxik7wPMjkMqNFnlKlpty5dsYeKH6B5uneZzZOwxQIp9z2LkL g3jTL3iOQK/w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,499,1583222400"; d="scan'208";a="289548237" Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by orsmga002.jf.intel.com with ESMTP; 11 Jun 2020 07:01:18 -0700 Received: from orsmsx609.amr.corp.intel.com (10.22.229.22) by ORSMSX104.amr.corp.intel.com (10.22.225.131) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 11 Jun 2020 07:01:17 -0700 Received: from orsmsx603.amr.corp.intel.com (10.22.229.16) by ORSMSX609.amr.corp.intel.com (10.22.229.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 11 Jun 2020 07:01:17 -0700 Received: from ORSEDG002.ED.cps.intel.com (10.7.248.5) by orsmsx603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Thu, 11 Jun 2020 07:01:17 -0700 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.102) by edgegateway.intel.com (134.134.137.101) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 11 Jun 2020 07:01:16 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O2axmM48QS5io+s+k8dvjG5GydMba5qn6vRhFCgLJmc6Z/T5jvdIYaIj60fz/NTlgw8hOEliZN+3TFjVkru6YZoFDhAnADd6y/pGsm94+AKx/0mCD3Z1WIJSojz3rHZMjRCsF3zhL9sYHqMJprTJkvqFSEFO3cMMmS1jYIwULR0372JHMpyip3Md1a6gGQpCPFkkobT89iq5y+6xAeSuHJl8rtmp4mEnpMuyBtBN86xYQzxdY2hLbv1/n+IfjzJa11hPba8EHkFzsCC8YhExvkmBsGBgv8nqcf1m3J+7ZKi90MAyELaZ3Mf4T2gxGRdYu63mQ3MofC/CuSko+3aYLw== 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=jpfS3c+t4skF2QrMWvd0PFksZNmu6Hn9LzGC6BPJnBg=; b=F3K2Ax/6O59bN1VRn0erILtSuzppbWRc0PR358GXMbp+3umtrXyE6XT6l5I4x4UyPG9CCJ8HoZMsWW/woA0VtV3PShCKFcVPwI071UYZOIiv1RKeNn3V6qEcPn0h/6neJg8lPiUVBgjBcTL6HDf8gFKzJcQQX6GdpmUo3KM9D6Cyc6eEGLVOx23WL5Utn9t+jcJsmtFvOU/xAIBAmdSWfFmeBHhvpHm0fTfRxBISdaAWtju4QAHN/xSAT2zOE/hjpT8jEGh9QMjTVa4R05jZMi4+gGIKllAfpOLmqqNMKbXoT1H+29DsGC5ldCS/0QkUfM0wK3+oixil32ddWyfSkw== 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=jpfS3c+t4skF2QrMWvd0PFksZNmu6Hn9LzGC6BPJnBg=; b=l8cqVh8NmQLizlFOihE8Yz4VjGMcDh5yTnsrUJEUYkfwwcRG4bE00WJXLO5HSYGm50RMGI3zO3iO/Aa3kui3qaVcYtKc8Ti8A+pimA5b9A+GqIhWV26t+NUsgZRQa1bhTXJCtq5jEIVvHoC3sWy19yCabOv72WLx9QPvSZ5Hs4A= Received: from MN2PR11MB3550.namprd11.prod.outlook.com (2603:10b6:208:ee::21) by MN2PR11MB3598.namprd11.prod.outlook.com (2603:10b6:208:f0::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.20; Thu, 11 Jun 2020 14:01:12 +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.3088.023; Thu, 11 Jun 2020 14:01:12 +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+U2sUEh94t53P6jQRvZAgAFjRwCAABLg8IABm7iAgAAFnjA= Date: Thu, 11 Jun 2020 14:01:12 +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.171] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7a0ac633-85b4-4ad0-f2e3-08d80e0fe650 x-ms-traffictypediagnostic: MN2PR11MB3598: 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: 0431F981D8 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: u4fV2moYkQjX9bcjsUZIetYgxkTt4Czw0+agnQnPk6Q6kHHnFubgRi0Cjto077S8o5y0xvDFGNImTsT1vVv6kZjvAALZuVI5rFvQ3GbCPgQl6KXe7Fsj4jyWtwo+TlmVzs0bqchdyHKAw164+WJCNcAiCXV5oxjP5vmCCYcCl1nu9KGBSdZcmjQ1AKhGBo2XWWRPhKEMyIGoXIUzpLXhNwIr8ZSHllBsGMbpUliljWIs7iPCVqJQLaqsDWASE+aWWwZF/drtreibIMvek9cg/NnFBDTvNE2XAkjY4tl7aDxllZepId7YiPrtPsfni3eYY5gEhswnGfazfEvyTc3jxmnSZwLoNgQuSu19y/qPbT63tkgBbgD9sneeO3QEvrgd 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:(366004)(39860400002)(136003)(396003)(346002)(376002)(107886003)(15650500001)(26005)(7416002)(7696005)(6506007)(83380400001)(186003)(478600001)(54906003)(6636002)(110136005)(316002)(4326008)(2906002)(55016002)(5660300002)(8936002)(86362001)(71200400001)(33656002)(66476007)(9686003)(66556008)(64756008)(66946007)(76116006)(52536014)(66446008)(921003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: HthjTxdq5BOqd7p8RWWFfMQS1/Ev/Vqndcm5aGkndSpzOGQGCzNhUcL32cFwgSkCiT0xzrqPYWS8KOco4C+6ydfstP4/qIv+O0OkpmVQBlBcZCbcn48yC10TmgnyeiX980lpbhamvV8tX92ygnpoXKzXrie0uiXnIJ3KNC+bPfSJtKK62PEvPcfU8ozppAt7/c9h2YKnUf7Mb1s4al05tPGsIrVfwsUehSOVR0+HrKD096rFnoQqGj0PcRhVIfp0E8MVdzzTh47cAw2TQv7lFg3Pe43h3CJ4VP0/0LOfJzdjMN+Conhol6cp3dpW/PgOjxkZ3sbdwz4q0dWxz9niCk1c7d52Ls+NsEdo3yH641IkWVyrgFVNsQQ61rbLVmhPbrFGxwkY4cHzGAeO/CyBLAbyZG17oG8CbQ0UP1+AVKT3bb1o9zoQUAS/w+Wa5LpqBwKeyfohwbsVAzVgQQSvbbVxDwnQexQ4H2YT+HG8kWN4fAQX93MTMc4V6SjeKTs9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7a0ac633-85b4-4ad0-f2e3-08d80e0fe650 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2020 14:01:12.2269 (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: jTEnKYtn1gKlu+61SA93Kt2PQYTzfDY3cYkpla6OPrXn3md9fs9Gy/Sf1hYDe3HtxBYkAg0Z6gpUEbd+szFQgQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3598 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 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 > > > > compiler happy > > > and didn't create a circular dependency. > > > > > > 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? > > > > > [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_cryp= todev - > 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 > member inside struct rte_crypto_sym_xform union? > Then we can have rte_cryptodev_sym_session that supports docsis stuff. >=20 [DC] Because DOCSIS protocol and CRC are not specifically crypto related is= why we initially went down the rawdev/multi-fn route and now the rte_security r= oute. I think adding docsis xforms/ops and CRC related data to cryptodev would be= adding too much non-crypto algorithm related stuff to this library. There would th= en be some protocols like IPSec and PDCP with their definitions in rte_security and ot= hers like DOCSIS in rte_cryptodev - that doesn't seem good to me. Yes, from a DOCSIS equipment vendors point-of-view, who already use cryptod= ev for just encryption/decryption, adding DOCSIS to cryptodev would be best for them in order to get better DOCSIS support in DPDK as it would mean les= s churn for their applications. However, from a DPDK point-of-view, I don't t= hink it would be correct to do this. That's just my opinion, and again I'd be interested to hear other people's = thoughts. > > > > I'd be interested to hear what cryptodev/security maintainers and other= s > think too. > > Akhil/Declan - any thoughts on best approach here?