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 8CAFCA04A3; Thu, 11 Jun 2020 14:21:21 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BC8052BAB; Thu, 11 Jun 2020 14:21:20 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id BA2302BAA for ; Thu, 11 Jun 2020 14:21:18 +0200 (CEST) IronPort-SDR: nVyufPL29dJ52BX2CsmfTJdewy3B5TV3Xf63UUQxvYzmkPG9XHahPTGHUWpQ5mfj62crJ78Chz x3FmNuj0qzRw== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jun 2020 05:21:17 -0700 IronPort-SDR: ThszZNQk3IAU0Oyc0btxi1KtdDpQ8PSsSpailVgCpXicBdkXYckY8LhN/XJAV87FlLHULFj0fH DDkzll0qnoKw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,499,1583222400"; d="scan'208";a="314801397" Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by FMSMGA003.fm.intel.com with ESMTP; 11 Jun 2020 05:21:17 -0700 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX106.amr.corp.intel.com (10.22.225.133) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 11 Jun 2020 05:21:16 -0700 Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by ORSMSX601.amr.corp.intel.com (10.22.229.14) 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 05:21:16 -0700 Received: from ORSEDG002.ED.cps.intel.com (10.7.248.5) by orsmsx611.amr.corp.intel.com (10.22.229.24) 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 05:21:16 -0700 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.169) by edgegateway.intel.com (134.134.137.101) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 11 Jun 2020 05:21:16 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gWXRbsM5DQPJYmEZlYng4G6ddM4TPmRrGX0TnoluQB9uXk0YwDEEBgnvQ5aNPweWJ97MbcEdYolTd3DfizLrZ+PcBMHPTE66vGGnE+N0nYiJGZNQIuDnPS9MS69RBPPJ7rE9Ag927mAGxxzW4zGkJ63UKO56efengtICmReX2Am3FrhttjiwfuUawXiyTrYf3ozDmZT5ZRvb1UlaPga22V7iL/d7wQpqhd6vfuopn74JKa+4D5JCqk1lgfp4+rp8mYIHPUxyv1+C6ZDAXDYNmPMhCkNpKm4EDqMF2BiRfpFEkSmKdoF7gocP/kUtE1frcX3eQKTaoQazuRowC7qaMA== 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=3l8lw5HywolCkvKzTVimMlpe0f3qiAsgNV4BvT21Qtg=; b=QrwApRttjr5nepk5fiMHGLEpKeBIrgeozdO517xURWjadNF4jBptjdIHKOq7SECGsZtTW2LeE2RTt5z9eO8HRvxjwOZl0R16JiEKNh/3lqUf6bY9EzgXrOsKP2vuceUUgD3GwJpdF/yB7F3OpWzSjZRJgqJLQAYNpCooEGYxKxrstLuKcA2t5WtKMPSv7X6l2+SlA6sGPNMIaFOcGgkgvy0pcxsWA+Bef5VWThJcgQbOzxcx3lcpao5DV+oFWlHQEhsJk4rqcm6WiK5BvV9hH0ZWFhp4vwbbiKQQEOP40Dc4KhxxzFKwa1aBQZMa5fm3kj+iVYzLO6Jg+7AloAlrKw== 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=3l8lw5HywolCkvKzTVimMlpe0f3qiAsgNV4BvT21Qtg=; b=d4HAJrjCQUullc/oH4fiB1rhIhq7HadL5jtX1r2rSme69PKcMiDLdwD7k5vdsVxsApw/zPxvLS4S/vLQNhRkx5r8teUWSWBO67s5jQmWJ8Ybs/+y9dtUpULZweVoaB5gSDvVL2M0enWS1v8siGjp+/CEeOlC6sCywKqvrxL4J4o= Received: from BYAPR11MB3301.namprd11.prod.outlook.com (2603:10b6:a03:7f::26) by BY5PR11MB4241.namprd11.prod.outlook.com (2603:10b6:a03:1ca::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.19; Thu, 11 Jun 2020 12:21:13 +0000 Received: from BYAPR11MB3301.namprd11.prod.outlook.com ([fe80::f160:29ab:b8f9:4189]) by BYAPR11MB3301.namprd11.prod.outlook.com ([fe80::f160:29ab:b8f9:4189%6]) with mapi id 15.20.3066.023; Thu, 11 Jun 2020 12:21:13 +0000 From: "Ananyev, Konstantin" To: "Coyle, David" , "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: AQHWOoWN4GXDndi6U0mcdOcaf+c++ajQS72ggAAJCICAAVwvYIAAGCuAgAGVhDA= Date: Thu, 11 Jun 2020 12:21:13 +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-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.2.0.6 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.170] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2396c72f-e301-4413-3d5e-08d80e01eee6 x-ms-traffictypediagnostic: BY5PR11MB4241: 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: p2A4o7axuXXQ7kIoi25YMyX+3q7B3u6HRivIB7UxJKydsILzJ6uxgyZ/GR/D1CAgyOQQwDjrQ7gA7xw0ea1j4mbgAU1zX4NkdJYoA2lVr9Q0HnNSSt2YqCnErljHilMEFgsYsFF1SN81wNi45LV8Y8JpXlzf4QhjEWFniYMXI/DtzPw3RjNplVECFoFTmc6aE9qJ+mlbD3QIe4t+gt0TCB45BOccgk3kqV0QcBsLp0Llx1yeeSIIZpr4y6rg6kJumMDUrD/J0SgOmpDZO/7y8hcKmasscYKUJDCug++8w53iryZLWLUiCQAWEyq16sx4QG8k22ocjUbP1OibbPfpAqWXDzAi/WnlcV60QU8tc/bF1WEMgyo4OjmYcq8nDrr/ x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3301.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(39860400002)(346002)(366004)(136003)(396003)(376002)(9686003)(107886003)(5660300002)(316002)(6506007)(6636002)(4326008)(52536014)(7696005)(55016002)(76116006)(66476007)(7416002)(66946007)(83380400001)(64756008)(15650500001)(8936002)(54906003)(186003)(26005)(478600001)(71200400001)(110136005)(86362001)(66556008)(33656002)(66446008)(2906002)(921003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: RmHdBXBB1S4Su6HjxbMjH1B2jEIpxSFC/2kmjoeNXMhRWq+sY2yRDY04d2rGPXJbalVE3YmOHJHmVDInBo9BAld4cYenUgxe6AvlyJNMuD14RHISzISA0MiO4Ahrb7w4MdiSp+ymoJp3Aj+rHf3UMnqzDTxhpb9lHSQ2E+T5hrhPJtFbbisT0+8Dx0QwJDhuyVUy9yJo29OmfT4VROH6iTHiJXsxiIbwo1m6TuSQIspy+dKCw2zSJ+MNDYuuyO/8Kl3S3bHgNaBTXBr7N514Wuu71X+hivNIj1mMYEsx9naXjCrB94CePPsMK2u16UKuMpRiy7uTNItyeBme6L3CI1+r89uGm+D0OVupnx5FJ70gZrg0SV+a2cV3uLbrZWlBu6INDB/JplCXVW6FYTt8LSUVpn3fUU8I9vK9Qp2K5l2FwWUVnjYB8aATHWSJ63lMS52g1hYNmg88el3BMK8Hv/MVCB4/3NC3pRZ5LYw3QWbJiFkYGs4STDYABIvL50LM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2396c72f-e301-4413-3d5e-08d80e01eee6 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2020 12:21:13.5469 (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: gRSl58+a17mxWjtPB7aor92fHYd3lc7TuqBwz59QvUbQMlKNvd2APtTl5HqvCESIpry774yGISNEqmQkhoX6hHc2JmLncQnQyRQ4FNjHrH4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4241 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 David, > > > > > > > > > > > > > > /** 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 th= is 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 th= ough > > 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 compil= er happy > > and didn't create a circular dependency. > > > > I see... would it be an option to name this struct 'struct rte_sym_docs= is_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 goo= d idea to be putting > protocol specific structs like this in rte_cryptodev - that's what rte_se= curity is for. > Do you think it would be ok to do this? 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 memb= er inside struct rte_crypto_sym_xform union? Then we can have rte_cryptodev_sym_session that supports docsis stuff. >=20 > I'd be interested to hear what cryptodev/security maintainers and others = think too. > Akhil/Declan - any thoughts on best approach here?