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 6066CA0350; Wed, 24 Jun 2020 16:11:36 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9423D1D92C; Wed, 24 Jun 2020 16:11:35 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 75F5D1D913 for ; Wed, 24 Jun 2020 16:11:34 +0200 (CEST) IronPort-SDR: OMfhs5CTPSL49EUeXSGpb3tm4IjyZcyD0MOBvS1iu0t0l3zNP11bmnR3pih6xlYlgA6ecC9i5x wf1h8Ug8ankw== X-IronPort-AV: E=McAfee;i="6000,8403,9662"; a="142693101" X-IronPort-AV: E=Sophos;i="5.75,275,1589266800"; d="scan'208";a="142693101" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jun 2020 07:11:23 -0700 IronPort-SDR: sOal32u0RRrS+fp0DLMvArVWrJ7lZhLtp9Ei7bKcx2Au8pUraemCWhQM31K3zsmK0lEJqqVkIi P+y8XH/IDE9A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,275,1589266800"; d="scan'208";a="452648726" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga005.jf.intel.com with ESMTP; 24 Jun 2020 07:11:23 -0700 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 24 Jun 2020 07:11:23 -0700 Received: from orsmsx607.amr.corp.intel.com (10.22.229.20) 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; Wed, 24 Jun 2020 07:11:22 -0700 Received: from ORSEDG001.ED.cps.intel.com (10.7.248.4) by orsmsx607.amr.corp.intel.com (10.22.229.20) 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, 24 Jun 2020 07:11:22 -0700 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.172) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 24 Jun 2020 07:11:19 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JTuBjk8mpRIbYdDwYb4oWUOI+PqiWo1TagrdRSie6uNwqysvQHqOBdBro/NnWJOFDiDluHoqqJwuhT2rnsgOtEhn3rR8oRBGyOrcjqxgRuo2IwKFXjMjJySLQXgDLwKhmo8jeS0NbWlzdImyXFGrP62ImQ2J7cMrHE8pWpg1/Bk8jRVxUJBsMloyUMZq9tnZfQNVhcO7Lq52ZCtkloN5/9RH1cM6LAMUFadfqwKj/kVJ7+6z461oE0vA0I7viH8FTYdXK1e/zCbfspw/ETQcyeU8oFsztU9cC+dzbR6BOeVaYIXX2wRDaoaZbi8xyYum+iJDdy4x+NAjyWlbM+EGPg== 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=ffP1HGX1+oRj01EQ1j5oTyK8kU+W0ZJXfIOcuh7WHEE=; b=VnbeIh3BfWl2IaXWbf3x9vNIiApXkGNWkxdWqegCymkMUGboUPp+YoJqmzEBMT08b21eg12Z9ibynKgkuOb2gEEfsdkLLywcyPLssZPOwyPtWW4nrvK27UGiM6JPPQdjyVqhRPdoiDe7ZbqrSJwkv7ce+563snNBSsm88x38r7YtRl75kxH+PZ9HdAXZs4tnJN8Nn3x7nIHPvyKSayuz3QEJnyyomBUDGmbXYyZA2QuYkmzqfPvC9VtzOAAo+Cd83gWuZrdW69BB08M/ukdhSQ3Vrnq5E+4tNI14aYa0oxBYX3QdOeQKR/o5PUgF/OKwS/zyvwKCOXMIQmw3IMr4ZA== 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=ffP1HGX1+oRj01EQ1j5oTyK8kU+W0ZJXfIOcuh7WHEE=; b=TI72WRKRggkVJtW1ejmbvFMXEzPbmhniNdQqP31pGwfUBmojzAsQNx0aX8wd5D/trqpvb5r7wrGIlQvvyQ7uy98Ainvxe/UBOGC/KfvB2l8wyFhVHh/8R7Fc4TO2wS9mNSgHr38WVTqBL6psnRHZzE+yzvMPY5AYQr7vJkAHAS8= Received: from MN2PR11MB3550.namprd11.prod.outlook.com (2603:10b6:208:ee::21) by MN2PR11MB3566.namprd11.prod.outlook.com (2603:10b6:208:ec::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20; Wed, 24 Jun 2020 14:11:16 +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.3109.027; Wed, 24 Jun 2020 14:11:16 +0000 From: "Coyle, David" To: Akhil Goyal , "Ananyev, Konstantin" , "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: AQHWPmEdkfXrksBA+U2sUEh94t53P6jQRvZAgAFjRwCAABLg8IABm7iAgBNFWYCAAUKvoA== Date: Wed, 24 Jun 2020 14:11:16 +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: nxp.com; dkim=none (message not signed) header.d=none;nxp.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: bc346bda-ea2a-40ac-add0-08d8184875f5 x-ms-traffictypediagnostic: MN2PR11MB3566: 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: 0444EB1997 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nnIrYFUYxs7D+9SRQM4enexJX7mV/LyPZyTzcy9CJz5dXN+D1c/DFuRVdfsZe4LLzRmN1LIAhqWeYXYT7k87K1QmNFUl/z9UqT1vNcTgw/auJqLjhLwzGMCDuyN/E1SN8oqcbg4OYuLrr4oyNMs2C/+oVPHynkvT/yzMlcE/0Vei/ulj+MAf6cGQ2jElH9z6teqdE4LQj4/MSZOJSNERV/VRGikhDzrG+7OH6CavuDs9wHLgW4tf36Ws8J1p3lkMz6dxUTymms4ZkoPHFvAYztXrU29CqFNEQNY7ZpL92w9Ds5cl6n9TpnYTe3fpiuQJ0UdROSnBrbhYnuB9xiZQrD+C6j6ujkmnEJxPrDLfOaYorxgVugxslveOgSyer46p 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:(4636009)(136003)(346002)(376002)(366004)(39860400002)(396003)(7416002)(76116006)(186003)(52536014)(8936002)(66946007)(83380400001)(66556008)(107886003)(64756008)(6636002)(26005)(66476007)(66446008)(316002)(6506007)(54906003)(5660300002)(15650500001)(86362001)(4326008)(33656002)(110136005)(71200400001)(9686003)(2906002)(7696005)(478600001)(55016002)(921003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: mIRlGMH856WgmOQ/Nedjv4FN0jDu30gR0ho7+YkG54Nkpvm0eOW6LD77LZK0bJmfRnPit7bLrHxaPli4BWo9jvLDHycMReT1dYyAwCm0YFjhD/6QO1arlI7ozvoQhE7XPyZXjf3U8YDg0LqgEKPCV1s0Vm725f7/6WtQw099G4GVCUoEZnPrEJ3H/HR/eBkeG5Nb5AU9g9e7X36FEv9oJhUB78knaAr3ERscN+JsOxkyX/eaX3Lq2w5t2H2FYM8oAv5vLaHKJtlzwm/G22UE+EOe8ks93oe9T5zUoFAroxHYkhiRqo3ySSmQ9aS3JMmLaCXPWhV7M/VSBHIl5kiGrhv9YWIMP4/cnorR4JePUZS+tGm0MrmX16wVac/O8BqFrvXb/WeKlEuMYTicyNOuHHoTh/nMkMfVARX2CoNmO2zoY16++Uh8Emy6KzuAICXQdt+pq8JMNKjD6uWNa5nDz1jHw/FaKEdmr84I3ZQT1ezsJFqlyOnqoLkc7BLd4jeG Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB3550.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: bc346bda-ea2a-40ac-add0-08d8184875f5 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2020 14:11:16.5733 (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: DKcf7iw2kt6Tx9jCvuGcq470sScm/HOBm3z8egR/ttyD3/q23Ka0uWmnk1jS/QJfuSwpgxln1/5Hmo1mxs3O5Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3566 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 Akhil > -----Original Message----- > From: Akhil Goyal > Sent: Tuesday, June 23, 2020 7:38 PM > > > > > > > [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_security 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 member inside struct rte_crypto_sym_xform union? > > Then we can have rte_cryptodev_sym_session that supports docsis stuff. >=20 > Adding DOCSIS alone is not an issue in the cryptodev. The intent of this > patchset and 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 combination= s. > However, IMO we do not really need a separate rte_security_docsis_op > structure, As it has parameters which are already there in the > rte_crypto_sym_op. This new op Struct is just adding extra bytes which ca= n > be avoided if we use sym_op->auth.data.offset 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 = for > CRC cases. >=20 [DC] I take your point that introducing the rte_security_docsis_op (and the= outer rte_security_op) structure is just adding extra bytes and as Konstantin men= tioned, unnecessary levels of indirection. I am happy to go with the approach of us= ing the auth offset and length from the sym_op for the CRC values, if there are no = major objections from others on this. This simplifies things and also means we ca= n now remove the 'uint8_t security[0]' field from rte_crypto_op which was never a= nice thing. Konstantin also suggested moving the docsis xform to cryptodev. However, I feel this would be a step too far for cryptodev and propose we keep the doc= sis xform in rte_security. It is then consistent with the other protocols like = IPSec.