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 A35F9A0A0C; Wed, 28 Jul 2021 16:38:50 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2877840E64; Wed, 28 Jul 2021 16:38:50 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by mails.dpdk.org (Postfix) with ESMTP id 7314240142 for ; Wed, 28 Jul 2021 16:38:48 +0200 (CEST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16SEFw8F013271; Wed, 28 Jul 2021 07:38:47 -0700 Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2173.outbound.protection.outlook.com [104.47.58.173]) by mx0b-0016f401.pphosted.com with ESMTP id 3a35pr0scb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Jul 2021 07:38:47 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m/xZBosnMb7kTvLQwalF0DtGSWoAamgk2JQwjYRdUv5qNuE8k8Wu7YcjGNDS28zj8eH9Pox2+C77V1rFDucwzJcOdxltYgp4tFVCQWLLYjTcoCTJtt8tIfpyYf+1RGud4dMEa305ZFgxuZY9dydgxx7OLiArgcHHqrB+L3K/Z6IG4n2oHjkbc4FBDaDssQdR+q40PvMfjF7zUQdlOuyNkR5EgQ6wL9tWfW2IKjjSR9heEgLpJVs+Ur8aLZkcDGJC8Y0L/YmS6qOzTS7jljM/oLu+QvafuW5OS19KO2RT/CKuPu5ahQIG0uzCbOJW9Bx20R5s4qvipUYXYZukhG82Ag== 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=LfhNpZ3AMOFR6bIiSygv3S9gT1aav8RmD46h4uzzvJA=; b=SSbfMcsA/6thSvAISqkOCqY7e4rmCbVKuiQCiS5+gcZc1du1tyZfYfbAwaImjUtPhrym7Ssbfl1ZT0nkykCG/XOh1tDgTkZUYachmd/UuyOgpKmqlaa6deMKkGbyr5MNmYwQygdfDO6wOZ6pRxJ1Aq9JZUXbo/sp6BhpavnYYRNiLwVaaL/Ka/fxPu7E1cBKNUtSm8mnWo8I/wi/fjlYjDbj0PYPjalWU4GDtN9/GPdWXRnnOsv77DtUukl74zqB5ehBZKLmzKnIy0MnI3uiFLHJ3VTbJaAXKqouUAqbvTClrBJyJBK+oUcciK1eMzP8uoDQ3X7TdkC5dVz3cpKpRw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=marvell.com; dmarc=pass action=none header.from=marvell.com; dkim=pass header.d=marvell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector1-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LfhNpZ3AMOFR6bIiSygv3S9gT1aav8RmD46h4uzzvJA=; b=hAfljoCjR7Tdg287lg3XYt7ZRWghX83pFOeef5IBXgROcfgv/0cphEseuD+hN6cXf19hxi7kDKYr7o6P4jEeTesQvRoGQ5LiBpFz46tMcmzpOtkuMoCSALob+EGeK+E4Rd4kRQPGf9FCoxZZFxBzgn4ghj0lUiDnjDdQcBagFRU= Received: from PH0PR18MB4672.namprd18.prod.outlook.com (2603:10b6:510:c9::16) by PH0PR18MB4622.namprd18.prod.outlook.com (2603:10b6:510:c2::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.18; Wed, 28 Jul 2021 14:38:44 +0000 Received: from PH0PR18MB4672.namprd18.prod.outlook.com ([fe80::b5e6:2157:8ceb:2197]) by PH0PR18MB4672.namprd18.prod.outlook.com ([fe80::b5e6:2157:8ceb:2197%6]) with mapi id 15.20.4373.018; Wed, 28 Jul 2021 14:38:44 +0000 From: Anoob Joseph To: Akhil Goyal , "Ananyev, Konstantin" , "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: AQHXfSwXL7es0wlhlEaNZgD4WrFrVatLXl5ggAnxoACAACF0AIABTI2AgACDB4CAAQP+AIAAITqAgAAWptA= Date: Wed, 28 Jul 2021 14:38:44 +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-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 451e9ab2-2a68-4ef5-bcc0-08d951d56702 x-ms-traffictypediagnostic: PH0PR18MB4622: 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: vBPm3bLunIQ2wCSxAsxzdjamPzOs5qv6lHDawU9K3dzSoVw7ApU3wUeGrKXdMDG/v7Y0xO0Zmc8ixmwyW6b4LY6sgJaj2NePuqdSX2WFMsuyYMT/35NAmzILjo7eG2LXKqAe/Y6dMfSAa4Uz2kS4C2fgFi8w5q7H1OvUrHosX+gYrmd9VqETMcMRy1mX7VJfAY5Xbm4G0QlZPwEPuT+1kf2tFv+p1j1S0iosia7IOihPdbJhvHKi2f/SD299iGiZHOIsZOSbwes/3ZqOJ9v11U0QCRVgavU6OiFzhleDnJbWfw4g3GsGeQdYF9DPpUiHaiQekg5Zq2ECCYu7UHlLwLSX+gu22PpOy0ZSgqKYy3GZmyYO8nRE9CZz0D3dTimL3L/lwlvufvPpMyqDOM4cTkC5VXbzm4YzN7S0K9PqKhxd4jbeGGSWmaQvbKehv7yGYiqnkNy+88HRs+wA2/5Q+RDrjlql6wHZgTLkRRfZci07I7gAhxuZYANX/apcGOdtE/uVaBqdRZv3gGS7SWGEvPFAFwogll1sBde36TLFDNj6p8rLrexoPxbXIMxNapnT1yGR8/Wadrk3eG6kEMkytaMKeId+UCZlC9yr4uMwcbzZk22pNvxl+AtConZTk9+Djsfmrlljp2Hdy4Ano6JXnLjVJbDujOM5FVZcidSXLMEgSN4lhmSZ2uP/HgJykt1aC3fm5rfMrJRKzgUxFM2aNCNT9n4xG6A5B1Bbdc+RDOvZ2jzDaH4+Kt1UdyHiNEzTFp59S5+qDLi8Ee72U1jVnykaFyWDG6islItRyf9dlIo= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR18MB4672.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39840400004)(136003)(396003)(366004)(346002)(376002)(83380400001)(107886003)(7696005)(9686003)(38100700002)(5660300002)(55016002)(122000001)(186003)(76116006)(6506007)(316002)(26005)(66476007)(66946007)(53546011)(33656002)(66556008)(66446008)(64756008)(15650500001)(2906002)(478600001)(86362001)(71200400001)(110136005)(52536014)(966005)(8676002)(54906003)(4326008)(8936002)(38070700005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?NeH3Dsb4BKUqMoT0hZo0ITAp7Iwc8GhpRf/JTI1kgpAQrXyEOjS1JhHDhT0E?= =?us-ascii?Q?5XTOWLmh46jl/G3czOesnhaFcjTLHLlVPZpOnsg0Ri6xcj5M9+uy3c42cHvp?= =?us-ascii?Q?6BqJkAETcO8pT03EFZZEyJeiXdbDXhwJYfNysmTfXmtNTOKPjgS//GVkbbFI?= =?us-ascii?Q?SkcSM5MbhbEySt1m6+jE6ZmaZdlKOVjoY3IeNTKHC7fCnHsntvuIjqWOaQFZ?= =?us-ascii?Q?EiNyKlFSYVpNTmodtGaDHdsJZCYc2nQKDjRIUAUIIE9TVoP4wxaMys24IX+V?= =?us-ascii?Q?N3FpmordfknD2+E2ZGrAF8T6qFJ4NdE4iRwlz0ftwioz3UkeMiCBDzKPiKUR?= =?us-ascii?Q?tEMYseYxpHKb3uP7WV0RQOZkp5viIjtZ0kBcaRII1sr+839s/UZIkx3xm8ST?= =?us-ascii?Q?rjllonjSAv1R3KHLZwmGoW+VEc7dtlHxTLyaAIKA7lwzkK+kA8Rumu4EhDog?= =?us-ascii?Q?NJo7O77LjQIs8HaEyut/dm1TW+Lnb0Hs+n3ottGGaLcc8gqMYDEO5bV0Fp8t?= =?us-ascii?Q?yDJk/yVZN3Htxvc6N2V7/J5cehfwdtWwBoPxTU2maaCzCQLEr/yZ7M5dmeHj?= =?us-ascii?Q?2DE/78mJgwgdy7zPktPcnAyCrfduDYqCcTELPlhCAqZuaDBlxOE8sHOBlllw?= =?us-ascii?Q?wzPXf1ZNxX3Dlhvzq8Yh3ZTqlpCmoK3U3Na0hE3xEkbUYfaKnV6s0SikNDaw?= =?us-ascii?Q?iqQWja1fga4x3vc9ijTmia3cCrN3hMbL2XHDxCD+QKg1ZYDbaBx/lZSL/WHN?= =?us-ascii?Q?94mY5aLlOqkVoTIp9t/qjRO/zFhz/mrkRTioTB08w6n9tjRc601A7Gmz8+1i?= =?us-ascii?Q?+6CFImP/8OVwgJAMjlS44ynNI2lHVgZF0rsmEZM8plLXKKJBwdzUrlCwrly/?= =?us-ascii?Q?lH70oWAQ/VnM5KaU5dtju5AiUx8UCFevpFJAu3PE1d8FqFhz8H/btskDJFMx?= =?us-ascii?Q?FvGrYrCmD5kWMcebaF7yFDtJBEMSFHIK1WR3/uQ7ZQKBou9wVMr/EEy9Qy1s?= =?us-ascii?Q?fpTZ+BzxqyMOFWONBzjXBNyz19zb8xrYWGNeeI+rKh0B9GDdbyUfo5FBaAKl?= =?us-ascii?Q?ZoB8kwjUrsjFBUjPzmYWj3jBNhu6bJBuEZviS1s+64PdnQEF3XuBS6xVuQLd?= =?us-ascii?Q?+eTy/au0y4WiRg0IWxbGMv80YBkuXs8DccwoNjHeWT5GTrw/YWUhB5P7zWeB?= =?us-ascii?Q?gwo50yziXT7N3FNP7G6JhSG+fy/Y93h9ipHoAuZUOaPegfPxon6GgWVfye9m?= =?us-ascii?Q?vbwLJNNzFdr64Xb78gUnCaRqNld5bTkKDo+3gbEokY7+NegDMgVsMI+M+8dm?= =?us-ascii?Q?gUM=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: marvell.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR18MB4672.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 451e9ab2-2a68-4ef5-bcc0-08d951d56702 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2021 14:38:44.5691 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: IADUwOkhaMu3KquKqgtZrXjxnfPgwhzbnUABnkdaGrjgsV/0HZSxVXuLFk1qISOQ0FRxvv+7f8mDMA3VPGZFRQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR18MB4622 X-Proofpoint-ORIG-GUID: olRcqOJdT5ujTAvBE-4ANBR1O6q42C1F X-Proofpoint-GUID: olRcqOJdT5ujTAvBE-4ANBR1O6q42C1F X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-28_08:2021-07-27, 2021-07-28 signatures=0 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, Konstantin, Now that we have an agreement on bitfields (hoping no one else has an objec= tion), I would like to discuss one more topic. It is more related to checks= um offload, but it's better that we discuss along with other similar items = (like soft expiry). L3 & L4 checksum can be tristate (CSUM_OK, CSUM_ERROR, CSUM_UNKOWN) 1. Application didn't request. Nothing computed.=20 2. Application requested. Checksum verification success. 3. Application requested. Checksum verification failed. 4. Application requested. Checksum could not be computed (PMD limitations e= tc). How would we indicate each case? My proposal would be, let's call the field that we called "warning" as "aux= _flags" (auxiliary or secondary information from the operation). Sequence in the application would be, if (op.status !=3D SUCCESS) { /* handle errors */ } #define RTE_SEC_IPSEC_AUX_FLAGS_L4_CHECKSUM_COMPUTED (1 << 0) #define RTE_SEC_IPSEC_AUX_FLAGS_L4_CHECSUM_GOOD (1 << 1) if (op.aux_flags & RTE_SEC_IPSEC_AUX_FLAGS_L4_CHECKSUM_COMPUTED) { if (op.aux_flags & RTE_SEC_IPSEC_AUX_FLAGS_L4_CHECSUM_GOOD) mbuf->l4_checksum_good =3D 1; else mbuf->l4_checksum_good =3D 0; } else { if (verify_l4_checksum(mbuf) =3D=3D SUCCESS) { mbuf->l4_checksum_good =3D 1; else mbuf->l4_checksum_good =3D 0; } For an application not worried about aux_flags (ex: ipsec-secgw), additiona= l checks are not required. For applications not interested in checksum, a b= lind check on op.aux_flags would be enough to bail out early. For applicati= ons interested in checksum, it can follow above sequence (kinds, for demons= tration purpose only).=20 Would something like above fine? Or if we want to restrict additional field= s for just warnings, (L4_CHECKSUM_ERROR), how would application differentia= te between checksum good & checksum not computed? In that case, what should= be PMDs treatment of "could not compute" v/s "computed and wrong". For soft expiry, warning would work fine. Thanks, Anoob > -----Original Message----- > From: Akhil Goyal > Sent: Wednesday, July 28, 2021 6:29 PM > To: Ananyev, Konstantin ; Anoob Joseph > ; Doherty, Declan ; > Zhang, Roy Fan ; hemant.agrawal@nxp.com > Cc: Jerin Jacob Kollanukkaran ; Ankur Dwivedi > ; Tejasree Kondoj ; > dev@dpdk.org; Archana Muniganti > Subject: RE: [PATCH 2/2] lib/security: add SA lifetime configuration >=20 > Hi Konstantin, > > Hi Akhil, > > > > > > > > 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. > > > > > > > > > > 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 > > > > options. > > > > > 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 > > > > variables > > > > > As against 1 variable in option #1 > > > > > > > > > > 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 offloa= ds." > > > > 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. > > > > > > If we set op->status =3D RTE_CRYPTO_OP_STATUS_SUCCESS And then > check > > > for warnings with a separate variable there will be an extra check > > > for every packet even for a success case with no warning. > > > > Not really. warning will be within the same 32/64 bits as status. > > Compilers these days are smart enough to generate code that would read > > an check them as one value: > > https://godbolt.org/z/M3f9891zq > > > > > This may not be acceptable. > > > > I don't think there would be any performance regression, see above. > > If you are still nervous about possibility of this extra load, I think > > we can go even one step further and reorder crypto_op fields a bit to > > have 'status' and 'warning' > > fields consequent, and put them into one struct to make such > > optimizations explicit. > > I.E: > > union { > > uint16_t status_warning; > > struct {uint8_t status; uint8_t warning;} }; >=20 > Yes this looks a good option and as you checked, the compiled code look > Same for both the cases, we can explore this option. > With this union, it will be a single variable also. > The major concern I had was performance hit. But if that is not an issue,= We > can work on this one. >=20 > Thanks. >=20