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 7E0B3A0A0C; Tue, 3 Aug 2021 13:51:32 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3AAD3411A7; Tue, 3 Aug 2021 13:51:32 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id 94B8240E3C for ; Tue, 3 Aug 2021 13:51:30 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10064"; a="277425980" X-IronPort-AV: E=Sophos;i="5.84,291,1620716400"; d="scan'208";a="277425980" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2021 04:51:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.84,291,1620716400"; d="scan'208";a="584706834" Received: from orsmsx606.amr.corp.intel.com ([10.22.229.19]) by fmsmga001.fm.intel.com with ESMTP; 03 Aug 2021 04:51:28 -0700 Received: from orsmsx607.amr.corp.intel.com (10.22.229.20) 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, 3 Aug 2021 04:51:28 -0700 Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) by orsmsx607.amr.corp.intel.com (10.22.229.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10 via Frontend Transport; Tue, 3 Aug 2021 04:51:28 -0700 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.168) 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, 3 Aug 2021 04:51:28 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bZYx6qa7pvRPEsfmkZAvLmGbHISo9oQNXl8ym8bleIm2BFmuBMPuzlGrapafBUbblPe+ecQ1ZsU2y5taMyWPByu7eQEPmTD8hDLYQnMhBMChWqE1Fr8XZOKxKr1kw/isdaBOmXcPUhhBCPWsgijm4Av4tExKz//LJXm9AO/WgcXp6cfLTEmk5JlZRPfZ1hPfcMbuzfGLkXb3GlSdcZM6nqLgYP0RWjaKipYuXd/nhAW5ogSbOnKuzABtpMaAZIsTauznhPFDx3SB6zSa4VU8CG1D2iHRiNlb4MkEEa7SmMU7X7hHJel57Xpm4li/psohh4O7/QkwkL9NEOihhZEaWA== 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=kT8nym6O9SDoIFqLx59yyaKgB/9gd2We5Z/GPvBs/hI=; b=DTvBtAxfDgNQzqL9P25i0hFa1bVO/q+CLERkLd2rDIHo2qnd2RPAHh4L7wOkqrpb0xOmEPo7Mcw27sHgbIT70KOG54AhWKCRhgt385FDjYkr3LfHDdGThI7b8MgVoS3uE7pNaRvsQpBZ7aRQ2skwyhew/kxuKFlC1ZzWTVETUvCPqqCA4LpMQ0/Rh/dvKV8pgyUSKBE3digkI0rL0x09ZoADSj4eNvuCckRkLDXVX25btlgRbvnGUZm8ZzR94eiDnUoU7+y5G79IAE15C0wu+sX9AylA3sFGGhXE694XBeiZtL10t8Oawc6JnHEw1cwRByryvtT3jNRZaSRFSlj9ew== 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=kT8nym6O9SDoIFqLx59yyaKgB/9gd2We5Z/GPvBs/hI=; b=elZGneBHtHo3MPGfyzGbwn8l0ivv5xzTks+3J+grFrsnXsu7bv/7Vu4GZWzh+NF/sZzjxkeOUUIN56tk3a+1xrg/AATSVpKchPzWzPjNgsYJwdOgVjeC2rPxAT/9gkKsvkNQvEDwNX54ktXi5CnBxPYHTG0YQ/HSzMmPw+jFU3M= Received: from DM6PR11MB4491.namprd11.prod.outlook.com (2603:10b6:5:204::19) by DM5PR1101MB2169.namprd11.prod.outlook.com (2603:10b6:4:51::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.20; Tue, 3 Aug 2021 11:51:27 +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.4373.026; Tue, 3 Aug 2021 11:51:27 +0000 From: "Ananyev, Konstantin" To: Anoob Joseph , Akhil Goyal , "Doherty, Declan" , "Zhang, Roy Fan" , "hemant.agrawal@nxp.com" , "Yigit, Ferruh" 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: AQHXfSwfZZ8LQxx0IUyMwgdib0ZEGKtLZDUAgAnqBmCAACM3AIABQWuwgACOKYCAAO2NgIAAN6uAgAAb8QCAAUkngIAGFGgAgAHfTAA= Date: Tue, 3 Aug 2021 11:51:27 +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: c9a1d293-0ad8-44c4-c7ae-08d9567506b8 x-ms-traffictypediagnostic: DM5PR1101MB2169: 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: tSiJrG+rpQhl3nxrD9Xx/I5xzNm7pKpscfb/PGtwY+Mc8UQ7EWZvT2b2TNbOeA9Dg+8jthz/FINGtX9p0JV5L5JXP6rHy1H9ewEaiHbuOBXd1k+fE+ynpnkUkA7lJtYjxUpMU2LDkbpIe4qT0M/JYNKKOen0LEoGvjuAVMLS0Q5PPJex1bmEmgwEjyOt7TEiBmigLhWoPd2erUTN4ujifIqjlk+sqYcWzHFGLCvRUeZ1fp+bVOcqKEE7MQPay9H3KP1wKKrRYS7a8Qa1qCbqt+JeqnqM6/lEMMYFQZ3XpbQZQkQk+sMVbhE3ZwS5on6W3kFg1hfsrgyDijeIyCyZBNF2Ck8thJselwO0meli5/CspL1N9M8JzKgrV85h6iHD/bSuYdp49X6wH/EMIhnVdkBdw866rWrzIHjMCAq2cwinmP7SK2BlD12SPhCLD7aqhdcVtjZ8TTwolpVnf9PtB3nOcrZ5w4VaUzW0miPGuKJgSAUvavFLUve3jFwaI1QuYQ3hDPaSlMaO1cqXqpWe7vEKTRI/0vgGpKb2S8cj/sbwJrOrBouP+yJrXr0kCMYtiaBgUhQaY9QtMylzngubC9VRinYV08nhJ27PKIxxTfrDXibJ2L7Qyj61nUUGuPkH52WE/eK64auiNeIy/s3DvMaygzor+J2mVPjH9SHD4zUZEmiCtA7zfGagPlWepICl/tPziDOXReobdlnIJbfU+g== 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)(376002)(136003)(396003)(366004)(346002)(39860400002)(66446008)(64756008)(66556008)(66476007)(66946007)(76116006)(5660300002)(52536014)(478600001)(4326008)(2906002)(71200400001)(110136005)(54906003)(7696005)(316002)(33656002)(15650500001)(6506007)(55236004)(26005)(8676002)(186003)(6636002)(38070700005)(86362001)(8936002)(55016002)(9686003)(122000001)(38100700002)(83380400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?agUQjZYCHWDBnicxrFu141y2aTMDyjulZoSkOJ0LhaxoTFDCeEbIIQf7dVjN?= =?us-ascii?Q?DQdXf14qrOQgzxQaGxhBuVZ14/e5V0PCMIHnMvopFcw5pvyBbW+wOJGAhpve?= =?us-ascii?Q?TsvKq3y5+orzYXHWT/RRY+HpEdZuxmbahi9hXkWXhQI89sNTG7UCpQux6PgT?= =?us-ascii?Q?njxp4KXnBS4QniiiD5xiH8X5oLe73P+/+qy1Vc573OBfpPG1+jf4MrCRgHm6?= =?us-ascii?Q?0u65Zdb72XImDGYgejryOAjBDUhrKZZTZaDk801pU9nlT8C7Kg62agHlQXeB?= =?us-ascii?Q?3GZ7r+cTRzb4ANvV5S5ytsAVOQwRgShP5O5+xvZpOnNDghhGg3IEft6V6WPy?= =?us-ascii?Q?oNzAtc/9H/F1EfrH39/P1qxnUZGspHXCnGgyvonPMxeDOHYjAUo5QNuEZdwE?= =?us-ascii?Q?DBTHND9quRPpRj3K08vAwKKx5vejWkuRoyZcPNvlCNQQi57/9xbcw2cf7muY?= =?us-ascii?Q?5CzdX4SXQF9VvgxVVJJwMWsllzTtJEsRC+PNSOgD1eFjLCVTT4W29/KocuQp?= =?us-ascii?Q?+50Mhl6jGtUyrVEZ52LNKGnuMHRNuxUeuver0BTsxfBC48TsmENAm9HH47Vh?= =?us-ascii?Q?uDnXlQc2nLzJzq2tPx5CJcRhBwSgtskgPnafNjBgRV91wpv15W5pWN6wniBa?= =?us-ascii?Q?yvjUwkUiP2yve7URxDTu6eUc2t9eqIgpwgYES4FrUfB0I9mBKUQokwyFXrGK?= =?us-ascii?Q?Uv8oqzhR4/89wfo4hNHP1fqpr9qu/mWeF+eBSbBVq0SlMPYR/5Hs8zbuT4DQ?= =?us-ascii?Q?tYtctAXVHBtOpCMjKxSxVSY9GDk9zbmmiAayrbbo8kf5uuza4UaLah3m/3TI?= =?us-ascii?Q?oy+qcgV2l7+QfyChw5A9VV21N+M1eruGg45lv7yp78r2HEO5GVoyHNGEsw8j?= =?us-ascii?Q?JQXMIqzBKBKAFzrasie8UObMBXeXisiYkVss4Kh5RF9FGNPFPsh43QYQpwoD?= =?us-ascii?Q?Go+DSRAJ6gxrC9v1U1NTqlgkHbaeAWZY7aWuctSkKcTj9iW5pX5zENZKqRRb?= =?us-ascii?Q?SeVBosa3yKM/eC482FCXElzwkLqVFfh5dGwAGXfdIfeNdN5FQaH3uZ7g5uG6?= =?us-ascii?Q?BL457IQezmza0pzJVWi3+KknC+QxveJS7R38c1+CsbIF46EHUlLRQjTPVcuP?= =?us-ascii?Q?t8gginERomh7hI5K1nC305FA91FmygdFZ2P7KQCcLYrpw3sFqqreucDquABQ?= =?us-ascii?Q?1AdI3jf2jp9YQWm2k1PbMO2bDMEvv/AA93BJoUP2fKQEcgjjKvtCnN2O1h9z?= =?us-ascii?Q?rl/QwbcPsIGlosI6mFRCfM2kN+diqWMCCK8n8D/hQb08urY94uwYAM2KPyfa?= =?us-ascii?Q?K7cpsJCnCGEGZHXX7it5xjtH?= 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: c9a1d293-0ad8-44c4-c7ae-08d9567506b8 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2021 11:51:27.2042 (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: j5TsmN+21nGstibcSDflPUIPSXjLlq4QRnij1qa63zEflXuvhDZ+C+LbvtPTtGmhyut0qgyjSrssgA1m2j7jnspcp+I4NoStsWseON3QwzM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2169 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 Anoob, > > > Now that we have an agreement on bitfields (hoping no one else has an > > > objection), I would like to discuss one more topic. It is more relate= d to > > checksum offload, but it's better that we discuss along with other simi= lar > > items (like soft expiry). > > > > > > L3 & L4 checksum can be tristate (CSUM_OK, CSUM_ERROR, > > CSUM_UNKOWN) > > > > > > 1. Application didn't request. Nothing computed. > > > 2. Application requested. Checksum verification success. > > > 3. Application requested. Checksum verification failed. > > > 4. Application requested. Checksum could not be computed (PMD > > limitations etc). > > > > > > How would we indicate each case? > > > > > > My proposal would be, let's call the field that we called "warning" a= s > > "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), > > > additional checks are not required. For applications not interested i= n > > > checksum, a blind check on op.aux_flags would be enough to bail out e= arly. > > For applications interested in checksum, it can follow above sequence (= kinds, > > for demonstration purpose only). > > > > > > Would something like above fine? Or if we want to restrict additional > > > fields for just warnings, (L4_CHECKSUM_ERROR), how would application > > > differentiate between checksum good & checksum not computed? In that > > case, what should be PMDs treatment of "could not compute" v/s > > "computed and wrong". > > > > I am ok with what you suggest. > > My only thought - we already have CSUM flags in mbuf itself, so why not= to > > use them instead to pass this information from crypto PMD to user? > > That way it would be compliant with ethdev CSUM approach and no need to > > spend > > 2 bits in 'aux_flags'. > > Konstantin >=20 > [Anoob] You are right. We do have CSUM flags in mbuf and that would fully= suite our requirement here. >=20 > Our problem was, it's called PKT_RX_ and the description text refers to R= X. >=20 > /** > * Mask of bits used to determine the status of RX IP checksum. > * - PKT_RX_IP_CKSUM_UNKNOWN: no information about the RX IP checksum > * - PKT_RX_IP_CKSUM_BAD: the IP checksum in the packet is wrong > * - PKT_RX_IP_CKSUM_GOOD: the IP checksum in the packet is valid > * - PKT_RX_IP_CKSUM_NONE: the IP checksum is not correct in the packet > * data, but the integrity of the IP header is verified. > */ >=20 > But if we overlook that (& may be update documentation), it's a rather gr= eat idea. We could use similar PKT_TX_* flags for requesting > checksum generation with outbound operations (checksum generation for pla= in packet before IPsec processing). >=20 > /** > * Offload the IP checksum in the hardware. The flag PKT_TX_IPV4 should > * also be set by the application, although a PMD will only check > * PKT_TX_IP_CKSUM. > * - fill the mbuf offload information: l2_len, l3_len > */ > #define PKT_TX_IP_CKSUM (1ULL << 54) >=20 > /** > * Packet is IPv4. This flag must be set when using any offload feature > * (TSO, L3 or L4 checksum) to tell the NIC that the packet is an IPv4 > * packet. If the packet is a tunneled packet, this flag is related to > * the inner headers. > */ > #define PKT_TX_IPV4 (1ULL << 55) >=20 > Do you think above might require some modifications to document behavior = with lookaside IPsec? >=20 > Also, these flags are probably the best way for checksum for inner packet= with inline IPsec. So this looks like overall better idea. Do you > agree? Not sure I understand your proposal fully. Yes, right now inside mbuf we have different set of flags for checksum offl= oads: RX and TX. RX flags - indicate was checksum calculated/checked for incoming packet and= what was the result,=20 While TX flags define which CSUM calculations have to be done by HW. Yes, I suppose same flags can be reused by crypto-dev, if it capable to imp= lement these HW offloads. Though not sure what changes do you think will be required inside mbuf? Konstantin