From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id E85B6A0C4B; Tue, 27 Jul 2021 13:40:25 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 65455410F2; Tue, 27 Jul 2021 13:40:25 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id 20B0B410ED for ; Tue, 27 Jul 2021 13:40:22 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10057"; a="273503748" X-IronPort-AV: E=Sophos;i="5.84,273,1620716400"; d="scan'208";a="273503748" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jul 2021 04:40:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.84,273,1620716400"; d="scan'208";a="464256155" Received: from orsmsx606.amr.corp.intel.com ([10.22.229.19]) by orsmga008.jf.intel.com with ESMTP; 27 Jul 2021 04:40:20 -0700 Received: from orsmsx612.amr.corp.intel.com (10.22.229.25) by ORSMSX606.amr.corp.intel.com (10.22.229.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Tue, 27 Jul 2021 04:40:20 -0700 Received: from orsmsx605.amr.corp.intel.com (10.22.229.18) by ORSMSX612.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Tue, 27 Jul 2021 04:40:19 -0700 Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) by orsmsx605.amr.corp.intel.com (10.22.229.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4 via Frontend Transport; Tue, 27 Jul 2021 04:40:19 -0700 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.106) by edgegateway.intel.com (134.134.137.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.10; Tue, 27 Jul 2021 04:40:18 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ExtWirCnKUGDxyV9F4bLBJ8CjobDhMC0tbNyGMekgKcpC/aHdWcAHKUNPWTaUhIwIMs9KLi2SnzoIgrXyK2LlNtSayKmrKRPHlkqbkPYPMLWzwpjtCBZ94GaiC3ZeORN6HWr/zPN72+ujDEY8VY/LAFNMOiIj4QVqxv7fahLQ+AlCyHABtvXl8iq/us6heJkrHNqwu33/znUmou8pVh6yXedGkVze5GBPNhi758IFOu8XECyFWWbtY8IomNr+BvUANehWWCJdwgwmtB5kORLGsfLNUq5rygtAFQpYBbgs9c9YOKSzF7CojKki5gCIvNuRsYlK3S2AEu/+z0pdro8QQ== 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=03TCjcalIItaDc/T+j/M8MP4tbEU6UttCSH08EPdfPc=; b=SCL0Ujq4mePpkr/9I1gZG5DWyzcsbUYB/Blfy0X2XjeiALoCxVckzQ3azUJ7dNsQXHaqa/B/PV0M8MkM57IDtbLpfq+4Ga0UYJJaHOyS3S7DWoY5WlkQHtusb7Jn1C0EuIbp6KpDk9KkOTHgUhq5uvvDU+k1/yj/IOvlAIrzZbLjJA189OSTnuNEjJLxQFTzN344aeHtSWC11DK6r9gJbYSR+VmED4f9ULF4HFCESAe2AIBy6uAWat0oq493QOCKrQnJQyFcmLwglaCMfoW10f1VQD66wBkT5AxjcGWgLMGDNyMfFBxzbckZ9+tCm7DmRiyDNuCcaDf2ql2KE3Mm/A== 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=03TCjcalIItaDc/T+j/M8MP4tbEU6UttCSH08EPdfPc=; b=A7sEO8K/gJkUKcD1GDXB3/EBSEsFkkgDGAlXsk/4jf2JUmuNlGDBH4J/0+bvxcP6hWttv+fufS79zfsISSkZWAgo6YS57w1MYtT7gFn8tccW5QtQrEmYvAw4Epxa5ox0sYUMjBbCHSqi/EJCZNMerCfOcAl77JLwBk+wailSzZk= Received: from DM6PR11MB4491.namprd11.prod.outlook.com (2603:10b6:5:204::19) by DM5PR11MB1820.namprd11.prod.outlook.com (2603:10b6:3:111::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.29; Tue, 27 Jul 2021 11:40:17 +0000 Received: from DM6PR11MB4491.namprd11.prod.outlook.com ([fe80::7dc4:66b0:f76b:6d48]) by DM6PR11MB4491.namprd11.prod.outlook.com ([fe80::7dc4:66b0:f76b:6d48%7]) with mapi id 15.20.4352.031; Tue, 27 Jul 2021 11:40:17 +0000 From: "Ananyev, Konstantin" To: Akhil Goyal , Anoob Joseph , "Doherty, Declan" , "Zhang, Roy Fan" , "hemant.agrawal@nxp.com" CC: Jerin Jacob Kollanukkaran , Ankur Dwivedi , Tejasree Kondoj , "dev@dpdk.org" , Archana Muniganti Thread-Topic: [PATCH 2/2] lib/security: add SA lifetime configuration Thread-Index: AQHXfSwfZZ8LQxx0IUyMwgdib0ZEGKtLZDUAgAnqBmCAACM3AIABQWuw Date: Tue, 27 Jul 2021 11:40:17 +0000 Message-ID: References: <1626759974-334-1-git-send-email-anoobj@marvell.com> <1626759974-334-3-git-send-email-anoobj@marvell.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.5.1.3 authentication-results: marvell.com; dkim=none (message not signed) header.d=none;marvell.com; dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a815e7f1-4f23-4e38-b3d3-08d950f34e7d x-ms-traffictypediagnostic: DM5PR11MB1820: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qgdVVJfkR7sdJqmJgep6+62SOAUKILLLcmmcFmpGwFi0SMka6hDeMGFK/1VOleoTH1L7fkkL232VT8nMiF4gzQ4WQMjCiANuhfhNqEHaDST448hTxNFjwkJSe3C8uySAjRrkVu18h1c18DmzAuQDHKh2tGaVBqSbdFAnft/sjXVDXKl0cOtYaHhki5+UwEp+YmIhhujmdRpagz5vGVfabJrTyS2ZcFz+GbYEXDjHeT8rk8r+FXh4qMcw2/k3GaCDm6R9bBjrW/cvR28YitHXfdFX5cFekEXhKbn4P1F0qRsvAwwdrbnqCXNOi116MLxuTJbwdQDSLGay5V5q7MQPA1056wGY8Qa4zNQAM3v9OOwo+NISsrCUEJWO+HxYSkGQKpmlvCbAqCX4OIAo7LkiFgp6GMU2SgaiFazUEzqjDJ1JRRZvp8dfVo3f9SbBpWCpbt6+oM9OEJLJANe6ZuC7QEaQs5vjsD9BVWhHnaT1R0GNxda+fp6epyhbY7T9VonxAtVGgoHwczfRJZcGj0HbI3p0TsGxFJJEJhIUSkiRZssfX/ynFXW+fwansbQ0pvijoBmVTR8d71izpH7JxR+iFj2fhZV8nEf6JmgrOh1PKxICFZedaBHupnnKVLWf8CsK62eZc9aWzkfQZmerhqCq/uvzHQnU/q49lqz4DmYU/QshlUzVdmTFp3lagTaMVMpVUPPXa4l+jUCGHQhj5pRe+5qksMpEAPJ0nVRIGaco7uQp/vk4+n3n+E5tGIDsF0UqRO0i2RcI1k64IHqz04dtOz0MJoLbqIBPsx4IjiXIDFYgprFpDAnKFqlXrR05+JCt6MeCPns7xsY/C+VpOYnF0A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB4491.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(39860400002)(366004)(346002)(396003)(376002)(26005)(66446008)(38100700002)(7696005)(316002)(66946007)(66556008)(64756008)(55236004)(66476007)(86362001)(52536014)(76116006)(110136005)(5660300002)(83380400001)(2906002)(71200400001)(186003)(122000001)(33656002)(9686003)(4326008)(478600001)(8936002)(8676002)(54906003)(6506007)(966005)(55016002)(15650500001)(38070700004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?9gYTM//KdeeWyp1mIzi3laLs+kYty/c8RZSouDhy2slbINlittUyJ9hUl3zb?= =?us-ascii?Q?EcuvoWqwugVAmimFFVr97LPYAMHO3WvOj93LJ4/3AHO07IG6L4Gz2fRwzloS?= =?us-ascii?Q?MhL3sbYY63EE1Orv5rA2uapRC7ViobSZ79bILn48tN5gMOTOir2YVo45IPXT?= =?us-ascii?Q?v99edsenM93AuZqfGwMOpS2KBicM4VFEFL6ADxO14OzT9wUe/OZbj5Cf/kJ8?= =?us-ascii?Q?zltT15t6SvykcDbt4VxugGJW2PDEGAIq1a6pgPeyjCxFl30EaitLsmL2vdoq?= =?us-ascii?Q?4eO8VqYmP+u8hehAXZvSybYRgHrJozDvZ+bd7FGx+pIKsCwGiwAtfZ5YGR/7?= =?us-ascii?Q?553HadVE5XHiG5+bhlcEdRtidbxK1dKe/oW8RqV24CqqfnCHSrTz2L4o5XSZ?= =?us-ascii?Q?SQMHGoHhKxJPOPmG60cxVg2OMaXa1vyY8nTcYko6zs193lwArqwM5vLC0tK1?= =?us-ascii?Q?r/r9bzlg0POoqfc7L5Fag7NNi+/kl3HMpelln7wkQTt80bbXR0B9u3ttf5Bf?= =?us-ascii?Q?6wM5kj17+V73uTqmKmd3LhYclcDwPkzwyeqNU9C12RH0nffY64EJEv1iMXR4?= =?us-ascii?Q?zOxGm6KbvQxAeXCMWopxZ5Kc3ixe/ebPwkng2rPP0b631OM7G7pSn15pdF50?= =?us-ascii?Q?3uTVTgoH8/SAppWt/4m02XC/znvwit4VMMXL80FvSuPCfxIVvHmFb6rIc+B5?= =?us-ascii?Q?59xnwdejRR85v/jTgAQBGIphFZRuci8ajXqAk0AgtxfmKAoG5ce8F1mcVqUF?= =?us-ascii?Q?w6MBSmBoHKkCiGQoqCW1L6Ka+zp3W0kth3dPalfxZdljPaqHc70el4SEtNtz?= =?us-ascii?Q?HgFoNlOvxFW6kd9VY+vU+zVRkfHN55RUj3rI2H1xSDFez4svfN5Eu51EY/8e?= =?us-ascii?Q?GcP9meFM4bpVBK/pKJe9fofFD4QsqjyESxomxBa/tXLnoWed/ErtCtZQYqCS?= =?us-ascii?Q?4WKePeOWdOKyYR9v8HKXOllfy8sizXpOFgpzMcICdMQxKQIZZ2zH+7bFRGrK?= =?us-ascii?Q?z7h41jRuMN0iAb6iLh/MNMfyOD3GSVPMzoFRvZHqJP+3PM05utSErRlJVMJs?= =?us-ascii?Q?e6wwkrwcGXuAA0t0iKNP6F24LSwYh7n8K43fUpKb+xfeLjTaeyHcHZmw8kPe?= =?us-ascii?Q?27sSR7x9GLld1Enz/iLXeQg+9FpAKnDTWxu4WN+r2Vh88Z4nunzHyU0hqfIV?= =?us-ascii?Q?u9k9g6Uf5YsIUptUj0UqfEpUsv+TJUqKuv3LJz/MFaDLvSXYtN+4PYzmtjaq?= =?us-ascii?Q?KPM/+UKyICGRV0L473Kttn6HnsqlL5ArlbNDyTsMzFgbaLdtOUDqeDoloB67?= =?us-ascii?Q?DrOIzntpjbXC7of6a6ERVH7J?= 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: DM6PR11MB4491.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a815e7f1-4f23-4e38-b3d3-08d950f34e7d X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2021 11:40:17.2672 (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: Nmuirq5IjQy6deMPJhpsPVBEKAUPQgrzIQLKcEVTsiV0U/FnIg4n8XPjbQi8kkA9xRsgFFz/dgXHf7Mrxb/k8dVOeCfPspwi/Y8K5aal59Q= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1820 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH 2/2] lib/security: add SA lifetime configuration X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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, =20 > Hi Konstantin, > > > There are two options that we considered, > > > 1. Extend the enum, rte_crypto_op_status, to cover warnings [1] > > > 2. There are reserved fields in rte_cryto_op structure. So we can use= bits in > > them to indicate various cases. [2] > > > > > > Both the submitted patches follow approach 1 (following how it's done > > currently), but we can switch to approach 2 if we think there can be > > > more such "warnings" that can occur simultaneously. Can you share you= r > > thoughts on how we should extend the library to handle such > > > cases? > > > > > > [1] https://doc.dpdk.org/api/rte__crypto_8h.html#afe16508b77c2a8dc5ca= f74a4e9850171 > > > [2] https://doc.dpdk.org/api/rte__crypto_8h_source.html > > > > My vote would probably be for option #2 (use one of the reserved fields= for > > it). > > That way - existing code wouldn't need to be changed. >=20 > Adding a single enum or multiple enums is the same thing. Right wrt code = changes? > However, if the check is something like > If (status !=3D RTE_CRYPTO_OP_STATUS_SUCCESS) > Report appropriate error number > App code will need to be updated to take care the warnings in both option= s. > It will be something like > Option #1 > If (status !=3D RTE_CRYPTO_OP_STATUS_SUCCESS) { > If (status < RTE_CRYPTO_OP_STATUS_SUCCESS) > Report appropriate error number. > Else > Report appropriate warning number probably in debug prints. > } > Option #2 > If (op->status !=3D RTE_CRYPTO_OP_STATUS_SUCCESS) { > If (op->status =3D=3D RTE_CRYPTO_OP_STATUS_WARNING) { > Report appropriate warning based on op->reserved[0] > } else { > Report appropriate error number > } > } > Here both the options are same wrt performance. > But in option #2, driver and app need to fill and decode 2 separate varia= bles > As against 1 variable in option #1 >=20 > In both the options, there will be similar code changes. > Do you suspect any other code change? Hmm, I think there is some sort of contradiction here. >From Anoob original mail: "Both the above will be an IPsec operation completed successfully but with = additional information that PMD can pass on to application for indicating status of offloads." So my understanding after reading Anoob mail was : a) warnings will be set when crypto-op completed successfully, i.e: op->status =3D=3D RTE_CRYPTO_OP_STATUS_SUCCESS b) It is not mandatory for the application to process the warnings. Yes it is a recommended but still an optional. Though from your mail it seems visa-versa: Warnings are just some extra error codes (op->status !=3D RTE_CRYPTO_OP_STA= TUS_SUCCESS) and obviously each app have to handle them. So could you tell me which approach did you mean? If these 'warnings' are just new error codes and app is required to handle = them, then why do we need to introduce 'warnings' at all? Lets treat them as error - add new RTE_CRYPTO_OP_STATUS_ error codes for t= hem and that's would be it.=20 =20 If processing them is optional, then I think we better have a new field for= them So app code will look like: if (op->status =3D=3D RTE_CRYPTO_OP_STATUS_SUCCESS) { if (op->warning !=3D 0) { /* handle warning conditions here */=20 } /* do normal success processing */ } In that case existing apps will be continue to work without any modificatio= ns. Yes, they would just ignore these new warnings, but nothing will be broken. > > Again these warnings, it probably needs to be a bit-flags, correct? >=20 > We can deal with both bit flags as well as new enums in the status. > I believe both are same and in fact using enum in application is more con= venient > for user, instead of decoding bit flags. > However, it is personal choice. People may differ on that. >From what I understand from previous mails: same op can have multiple warni= ngs set. Let say both SOFT_LIMIT can be reached and L4 checksum is not correct. That's why I presumed that warnings have to be a bit-flag.=20 Konstantin =20