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 41861A0A0C; Tue, 3 Aug 2021 14:04:00 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2AA9D411A7; Tue, 3 Aug 2021 14:04:00 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by mails.dpdk.org (Postfix) with ESMTP id E07A840E3C for ; Tue, 3 Aug 2021 14:03:57 +0200 (CEST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 173C0n45027215; Tue, 3 Aug 2021 05:03:57 -0700 Received: from nam02-bn1-obe.outbound.protection.outlook.com (mail-bn1nam07lp2043.outbound.protection.outlook.com [104.47.51.43]) by mx0a-0016f401.pphosted.com with ESMTP id 3a6sfua6aw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 03 Aug 2021 05:03:56 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BQ6lUWgY70uoQFZ89x28BvJug+ozF/ovGoJvyizZ3PgNKnQPyHpGpOWA9R2bI2L/skyJsid3ijrvHQ/Qu+OEanyZqh4RO6HIBWsa2TwloBGuBDGG5Df0uvckYhxHXR9cYL5kC/WmMtH7gvB4zacmbvwEZkFLqLtd/5onsmB1Xr9reG/fp15yULP8zHvMZdNi8jK0J3a2GdsF2Ul+3w51E5aaFELJgR6TiOhQo6yTw75TTKsURJdzUjg81ztWoYF+gcb3+FdRAvaU+96a6vK+t7MrJ6bruCiYB1gZqKPZ+H85FBUx+jCYSPxrKA+lf4BoaRzKCuJkAaDszK/kSFjV8A== 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=2svX7GIe/LLBO98oFjilcgvizotERJjDpsIhLOPZRR0=; b=GTsISxciyIb+G8Tx6p00ml5kblmBRJrJe4VpyJigjKbB1tAoPDsL0GPzIarSv4ZNk0mzhE4JAYBvOxWBsyI9HT6BYTBW60GWgpfjfDX/S6o5crmAz9jwtxB71ZhW+UE+G1qhdZVyh59O8CAv1iE+gd/+/OrudvSPPWAdRgoWFvRW7UFU+TEotG23tiC01okNT9q27vT+G+2YfZFeGN1Lf4fkw6/ByfJoZ0Ctojy5GWbIPTBjxHK2xkeK2/8i02e4RNWuAG9HMdeVayAZIa2Dpl7JVDpfuYNfbeOIpf3p//7rIHHGBdrn4EUYo05+uxnNBfWgXX4aO0WAvrw91l5Q5A== 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=2svX7GIe/LLBO98oFjilcgvizotERJjDpsIhLOPZRR0=; b=WtXgBkAl9HtnllgngFceWWoApwxY53s682Bdg3gBGqYOcX5k+8q9dotPhR85XTYB4AxhNuHXxUf9YTG8N2QDunucmqZpH1wTz4p9kIKeK83m+r2UqTp5PBF2WdYZcaOH1fyRNxAQ8ddokKt7h01FfqHBvSZdA4wdrdS1DTMYYic= Received: from PH0PR18MB4672.namprd18.prod.outlook.com (2603:10b6:510:c9::16) by PH0PR18MB4523.namprd18.prod.outlook.com (2603:10b6:510:e8::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.19; Tue, 3 Aug 2021 12:03:55 +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.026; Tue, 3 Aug 2021 12:03:54 +0000 From: Anoob Joseph To: "Ananyev, Konstantin" , 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: AQHXfSwXL7es0wlhlEaNZgD4WrFrVatLXl5ggAnxoACAACF0AIABTI2AgACDB4CAAQP+AIAAITqAgAAWptCAAVBVAIAAB6/QgAfsh4CAAAG8cA== Date: Tue, 3 Aug 2021 12:03:54 +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: authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=marvell.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 87b2294e-e90d-449b-c017-08d95676c456 x-ms-traffictypediagnostic: PH0PR18MB4523: 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: +C6vtt9cObjfgL/kK481OUbJgiVVs0bM5Akl4zSBeAc4UjrlMuXmbYIGrY3VFWAdjCV1zPiS7SAu3P1S5RM0fN6N1qXsVavz74ypfeIOqsrqd6nYfAQnrt65K04rQllNHLyN8xl2G2L8rXKYhXFI5D9QJ/S6CcjEPYs+vMKp2ecb6UrJNCzRYEskAtqfrx1RzDhlTcIiFrZ+j7oijE873qGKaWo8wFxz19s2NH9HfystlcUDTATS2v6mFZas8tRnwpFsv+USvS75etZCqfvwXiiMIA61gbJiypA/Rzg+7tPhhU7Q5hNwnIjdh2roHlW/tMbzh1DxM4VjMN2hGwHFtxJ/H5cORzEMmGshbXB3stsoAnpEtsw93fzmGrroTG/mHPELinQadcOQu+v9zIAuj8ffdkwf2hZKoGAHKXn/pHVfA56LlLDECwqyM7O24R2rSKZvxsU6l/y5KOmAm8ew7hcOfsm1lza15zMlYd+aluRQLx/oL41P8e356jbm7PaiGA4Do9meliEHha+oCkViby2HaAVsONihHxUgFjUFQk4phtm65hDy9sWs0CPZHbOxhupQE5oXUksb4g/x8Z4GFyimCAxji/pswL3shlWaCa2dZLZ5miL41KT6fE8KtcH91wlJ5tIf+eXgpLi/fjWZthJdBkbS7EbE7QgdbvtRA1Hw0LHk+5/GjRiQqZijrc+uSk8H7AzwZfmrLONdejLuzXBlluso2Mo/rXcj0Q4It3U= 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)(366004)(39840400004)(346002)(136003)(376002)(396003)(8676002)(6506007)(33656002)(38070700005)(478600001)(64756008)(66476007)(71200400001)(122000001)(52536014)(38100700002)(66556008)(66446008)(15650500001)(110136005)(76116006)(66946007)(4326008)(83380400001)(54906003)(107886003)(8936002)(55016002)(186003)(2906002)(9686003)(86362001)(7696005)(921005)(316002)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?LXgOLJguTVn6roSXX+8RgiBLE3tWyf5DnHOL6h7dhXYO4jpEu2jrwR35T80g?= =?us-ascii?Q?TaaBgJNmVn6ddklHYOgM0dOV6Ua5Kd8fG1eZb0XzmKarbmLH20DaXVEsbxoZ?= =?us-ascii?Q?2OWTDw/xwKwX0JCSqE4ed0Pj0Ilf3Fj+fjYy0JWOlci2qmvxHYPrK0LsMr0r?= =?us-ascii?Q?C9lSVxiXy8tV625gvVY7mESsebIulOXoNKjw8MPsWZBXuar6eYvQy+7+xWjY?= =?us-ascii?Q?U2UGaonbgr3CRwCgqAYv2vvjaUZC8OMJEg7j+T4QdZrG/YaDb2WFPF9MnOEu?= =?us-ascii?Q?ttLYBBrSjX8/i9G5Cc4Xrx79whXeFpDqvjT0GqK5SvgQPYp0kX0omPFl47PR?= =?us-ascii?Q?gQ1LIZBR25p6CJffQjpfOsT8ShKyMKRR32Ypp7nmVQIQcakcmVi0vkVHiu55?= =?us-ascii?Q?sUNemCRJch1xMtE78ESv2NEHn1J+ptQMm9EbpWFe2h1uyQFGyio8k2Ur3kaV?= =?us-ascii?Q?Rs8X4NYFz6BtC/m8OuvKkD/DRhMk6Tx5zYyzBvQM9RAY3YuNRPkFrr6irC1w?= =?us-ascii?Q?tRDIXEd19sdc/wD0uqHXwXKgvqHhe2GkDSSBxiEfAERFKhGItIsgw++HrAai?= =?us-ascii?Q?xTtNCrhvy1fVtPmWJlNjVp4n27PhxzwPZBIc6RL+qFTIhHOpcsplguE7g68Q?= =?us-ascii?Q?s99My+2MXGC4kb0H3rT9knf1FhXcbjFBJjheVT+0VpiyFIrLtB84aOwo3mY7?= =?us-ascii?Q?d8Ha+vbU0qVajI/5I5YdbHcaCGEYS/iVJ01lWw2Ag9o9kJiXm+33uDfT9/VD?= =?us-ascii?Q?vCcKVwkZ7Px98j5oKfY0vvnt9Kf0iGRz94PfqaUYRVW4YefS6ZpZBsz72hBt?= =?us-ascii?Q?jrHt8s8Dl4M78Cs+QQA/G9WJgfc/x5l5XekqSmnRU87U9Tat0OnktPQxpN67?= =?us-ascii?Q?vMmpM1DkNxaSH+VEz1yqNeDRXEN15ztpUNJf4ByryNZlq7eMrvu0RhPNngHr?= =?us-ascii?Q?QjPpjW81R1hI9fzG2hoELSvnZwrn9A8W/rYMxAQLkExtswy7Spaq6dEIIe4O?= =?us-ascii?Q?sdT/ow24mJuUwzslcRoYJEFcw6+7R3+N1tKcyA+L6Bq0ZTwKDCQJ/pJXQL0A?= =?us-ascii?Q?h9dFQA3ZUWSHqpqtzLQtJdRJ+xLMKbGI/QtbBiOToaJC7AtzkwFiGOi+wm3P?= =?us-ascii?Q?J9Zpbbh5r7jltM/3JmZd8fBbSuWu/ilH5lHRZIDwiGWO5ATJoll7aft9vwnI?= =?us-ascii?Q?KAgocyhH2Yj2UBlwib8h+HCnUQGA8WguPYgk5zHHqOqrtcPjJWwy8TmfMZRr?= =?us-ascii?Q?2tBINAP6X0LAvSC+4QkeYmeqSxqaLhhoEiHYP7it1BVh/uke/lR7L7DjMdSF?= =?us-ascii?Q?5BFJT9LJvm1wgB2TVyg/bk4baVtwtlwuTX7nayO/uaR5W5FTRiUr3+yqkniS?= =?us-ascii?Q?cgF9nQp3AhXCPI/S2ifozUjCGDXO?= 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: 87b2294e-e90d-449b-c017-08d95676c456 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2021 12:03:54.7106 (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: mHFP1LwEC/814wtedul9QJeqqMo/Ly+ra24dNwGj48PU3PhR9o9UJvKQTs1dK8LcNcnVZS0XFuHzAF3r0MUOLw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR18MB4523 X-Proofpoint-ORIG-GUID: fCNG51EzHu6UEf_X1Lpr_A2rbl1yXjn3 X-Proofpoint-GUID: fCNG51EzHu6UEf_X1Lpr_A2rbl1yXjn3 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-03_02:2021-08-03, 2021-08-03 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 Konstantin, > Subject: [EXT] RE: [PATCH 2/2] lib/security: add SA lifetime configuratio= n >=20 > Hi Anoob, >=20 > > > > 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 > > > > related to > > > checksum 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. > > > > 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" 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), > > > > additional checks are not required. For applications not > > > > interested in checksum, a blind check on op.aux_flags would be enou= gh > to bail out early. > > > 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 > > > > [Anoob] You are right. We do have CSUM flags in mbuf and that would ful= ly > suite our requirement here. > > > > Our problem was, it's called PKT_RX_ and the description text refers to= RX. > > > > /** > > * 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. > > */ > > > > But if we overlook that (& may be update documentation), it's a rather > > great idea. We could use similar PKT_TX_* flags for requesting checksum > generation with outbound operations (checksum generation for plain packet > before IPsec processing). > > > > /** > > * 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) > > > > /** > > * 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) > > > > Do you think above might require some modifications to document > behavior with lookaside IPsec? > > > > Also, these flags are probably the best way for checksum for inner > > packet with inline IPsec. So this looks like overall better idea. Do yo= u agree? >=20 > Not sure I understand your proposal fully. > Yes, right now inside mbuf we have different set of flags for checksum > offloads: RX and TX. > RX flags - indicate was checksum calculated/checked for incoming packet a= nd > what was the result, While TX flags define which CSUM calculations have t= o > be done by HW. > Yes, I suppose same flags can be reused by crypto-dev, if it capable to > implement these HW offloads. > Though not sure what changes do you think will be required inside mbuf? [Anoob] My concern was regarding "RX" & "TX" in the comments, which are mor= e applicable for ethdev than cryptodev. But then, I guess it's fine this wa= y itself. Will submit a new version for all the proposals with some unit tests so tha= t we can discuss if there is any ambiguity in the usage. Appreciate your feedback and suggestions. Thanks, Anoob