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 1D289A0C40; Thu, 29 Jul 2021 12:31:54 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8F4B440687; Thu, 29 Jul 2021 12:31:53 +0200 (CEST) Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam08on2056.outbound.protection.outlook.com [40.107.102.56]) by mails.dpdk.org (Postfix) with ESMTP id 5721640041; Thu, 29 Jul 2021 12:31:52 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D8b1jEMvHWHUYRve+LXRP98ts/PwI25ztnonfey5AbFOU6i0OJSgsIXJxgFjMh03O52PNV5IY2uMwDqipJxHiiWTmNcUfV0Z7DmFGZxC70Pn/o0Rw04ZZ3rpobPNZkXeSTSq7PGShQ8ufJX69+isuvcm+XLsics12WeRZLiLnfWPg2kUuRCLUyWIk2wvS+pJAqSivTacWpvL8pzhpNoDpDvMsLsSakmc0BjKJDi69k/9xUBL+WkP0K5ipnvSpQHSoDi639jskO9b4lgVL/KzJX4Mok3yOxNbmRS4kNFTpIF3twFpp8T/ZMSVN5jSuVLxE6JgYqqdqpcUOCYC/Cg+OA== 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=/wWTwZ/k1UXMTDZJ5ODAssv/05iJli23VOrz1A3f7EM=; b=hSaIjPbNmRS7cMEmh9WFbihjQbdmO67nz/vVfmxrW/IS4bfXCATnDFCiDS2OVzmVL53lGGypCLqIJalPYcuoF3Dn/3r4nvBozTR/5oE88S6crXpdDARiIMRVtVDzfRTZEC6UKQ+DA9g6Zx9IQtJdfjOWn+uesGWS6iv8hzwWD60XBG0S1qtw8Q3QxynOlwtc0NPkpkJa8jht55NXnA9aavUPCAwCmCSVQSFE79AF0+MInlgQhrgUrNh3hZIDLr7yTazhNv2/+ApV7Cc603WlgrmZ1kvIEzOkHW85vuTcvqvZtkc1wrO1ZX7/SRwgCnRdJlEBEdN4t0Wdj5kdK0QWBw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/wWTwZ/k1UXMTDZJ5ODAssv/05iJli23VOrz1A3f7EM=; b=Hhl98alx15zNWZSQ8DD6on8nFStlCoKAg1QLPx77otkUJiFO2aCLsQ68EygeJMgozpFT420S1PluQUH1zqKld4um1BaDhCi8mv5B7eKgJl6ZpH2q45WXt1XM7TlaZhYwx1XUSzX7rzzght2LpyVRKvMVPOXRaPvByVAeT+EMPrVB3G+uebUXXIms1Lf72wD6RlRUmay690zaYKlWiSSVCKHVU5KxQf73PJHV2nNtd4gS7VJZlFJxJaQJgEK2M8RJh5vertg3lflQT9F7Z61WTV/WUkKR5Ss+jE8k01H/a63YnI/vIbYk3Lr/NgCvsrXAOCIZINwaReQgidQTBKR4Fg== Received: from BY5PR12MB4834.namprd12.prod.outlook.com (52.133.255.81) by BY5PR12MB4321.namprd12.prod.outlook.com (52.135.53.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.19; Thu, 29 Jul 2021 10:31:45 +0000 Received: from BY5PR12MB4834.namprd12.prod.outlook.com ([fe80::3814:b909:389e:4030]) by BY5PR12MB4834.namprd12.prod.outlook.com ([fe80::3814:b909:389e:4030%5]) with mapi id 15.20.4373.019; Thu, 29 Jul 2021 10:31:45 +0000 From: Gregory Etelson To: Olivier Matz CC: "dev@dpdk.org" , Ajit Khaparde , Andrew Rybchenko , Ferruh Yigit , NBU-Contact-Thomas Monjalon , "stable@dpdk.org" , Xiaoyun Li Thread-Topic: [PATCH v2] app/testpmd: fix TX checksum calculation for tunnel Thread-Index: AQHXguh4syGJazA4nE2s7L8tXYr5f6tYb2+AgAAQKhCAASErAIAAFh1A Date: Thu, 29 Jul 2021 10:31:45 +0000 Message-ID: References: <20210719083309.15428-1-getelson@nvidia.com> <20210727130757.30724-1-getelson@nvidia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: 6wind.com; dkim=none (message not signed) header.d=none;6wind.com; dmarc=none action=none header.from=nvidia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 045def66-71f3-490c-f4d5-08d9527c1072 x-ms-traffictypediagnostic: BY5PR12MB4321: x-ld-processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr 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: OnSxP5WHiLn024vSCWQi98S3dTGECgR/uvW45hHmW/TwgUC5ZREdvZhX7p6XksBP6uwuB4fRDZ0jzAdqxd9pQ8PLCJeVA0bjghCk0smiJsxaWSete2cTYIu/xa9IAmAKH7VcefVp/xo+w1CqjiN1IUNHLcEIBggbVYzQsCyaTyMsTRS49Nw05hvoWdLmsqo+yfNSxIL77Fmob3OGkC/hFgeY/C9Aob2rrFTzjhR9mQ4Ex4Vtn0Yg6UVJEI5T+i3ZDQGDGUg1Lxk8PX5YJrOFa1u51WBDJzwX0IMeGG2FtrANNXnig4oAhzyqkwIZ+kZJlZaNt0LJeXuJktN0sIN8TqrxzYuCmeeIlt6jItqHsmPCXjKE6R17O37XJu2YkBa9t0N56HuUJMBrJI9zPB4ElnzMu/4pN61LniQyyXMayFc2wtQ9NuRLxJi0GnOk7CxfqS79ZzKnhWbIgGHbonFFMaJH2++hImJ6UTFD4B51q1HXWZS7y0ky0xJsPiKEFPG0ZoOztc8wyeGjmY1hWrPzKIrn02ak10yyI8pbnCjrJEVSyg5rt7PmQDSmfajSxBb+e3pls8q7sg5RjC+FtMsI8YJwEhxaFwLNjr4zofcGSMvNnft5hA2q4jrKnPpQsTJtiAQBtD5zL+eJpQ94dSqy+tidTKEXW/V2+WcqJZHn5nTOHtM5OJGN4t2w/beovgotU/59tCtPxyKLSUZgPXbciw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR12MB4834.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(396003)(346002)(366004)(136003)(376002)(9686003)(86362001)(186003)(316002)(2906002)(55016002)(71200400001)(38070700005)(6506007)(83380400001)(26005)(54906003)(76116006)(6916009)(66946007)(5660300002)(66476007)(66556008)(64756008)(66446008)(8676002)(8936002)(33656002)(122000001)(7696005)(478600001)(52536014)(4326008)(38100700002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?QrOfTzPhMTnR6zMOn5wclgs5zYAy79jEFLahz2AAclrE0kprN5Jwf7tgcNng?= =?us-ascii?Q?eucW1v+xLY0QbZvYk7KgwVbDMbp7fMRLjWmfP2n8NiPkZS697Yzav1Wbn2Ql?= =?us-ascii?Q?x9S75ClHMMkVClkxLYbUkXsAJpdMO2rT3vYSrXNS1dRFose3J5rLVgymioPA?= =?us-ascii?Q?fZfm+xI0rC1sR6DnWdHQL7YKBPvluDMY8p0vpzfUT5amlxto2Eo/4QRdK8vH?= =?us-ascii?Q?FWeUblLhInMluhDsEix+exauHc7HZaxbSiqwi4hMWvrC5rXcr1Vgp05jxwmw?= =?us-ascii?Q?HysERCVV7L0hL9pdI7yOhXg0HwRD7HMjid2uJ4l8m2sMIct6lewW/NJNbuVZ?= =?us-ascii?Q?EMrtIBV2jdciXuSQyo9QPLiBBevU1S5F3VfGOt3wCc+Jkcuw2BP6bkMU23l+?= =?us-ascii?Q?UpkgNVmuFh8LvCAx4SFM67/YccLbr0r/I7bvEbEA5W/SsuPUQNl6r+NxNpWB?= =?us-ascii?Q?tNJ5XYFY9wxyZABREVh1xuuNs6oKv9XlAXPE3fhHGJB27kkS10Ht0YH0VOa7?= =?us-ascii?Q?rxPhZRtXZiuDnXVp9ZDKIH9re6l33Fs5zDZq4h6clqPgcao1ZXNSnrXfov1Z?= =?us-ascii?Q?zacS8macaNFTT0ZVI1HKCGNHvEyzg+UCzdpMg7g/S+cvOMOkVOKh2o+HBDe0?= =?us-ascii?Q?b769TgVmcvnDrZqb4IGB2TYFMXhpsBL+TQOJRCxLbCvnnxPBIdGe6MxUBjE7?= =?us-ascii?Q?o7LGz7z3VeOJxgJicwN7koW/zefWSbcDF8RAOYYtQDsTatrXiBG8yYkT+lZ5?= =?us-ascii?Q?Z59wAHwWhM1COAU0snXV8RCBo4BFYCVLNwyFtPJLUAqBSupLiC4R9/O1h+uh?= =?us-ascii?Q?F8SjFhq9y64y+AoRIzVIt2qd8LEOnUqYIhBuKDWq6e8sZRs+sPi658RK3zBl?= =?us-ascii?Q?45l9Zzpk1LnyK8fhEgNE58mm+1FiA6VtDstYbKOlmLXkoB5DX3OVRgltyEx0?= =?us-ascii?Q?qArJSrium20vX3W5pNzLZdZX+0sdKu0YRGNe81dZVTDPFIJsSNipFq4tVRnP?= =?us-ascii?Q?D8Q3I7DpdCjSwWfJr/U85WU2g6Wf+l7+XbP/oTjX+CrwvibNN1217lgI7ncS?= =?us-ascii?Q?1KUKhGvh1uxEO3OiVdUXTNEbXUrZ0br9k0zVCT12yIVHumMa43yB7licej6Z?= =?us-ascii?Q?un4g35Z5hP/idjYI+zqqdcDX1uEjgspKx30TBdisR/qp6QIfXgtFY9fVBP9a?= =?us-ascii?Q?iFUINJt8dV05Vl4iIRR0gYj2TPCRLSsRMgh3jzzDcepsdlnx/RJsKYADgb58?= =?us-ascii?Q?h00vE7gMCh69Aj8GHwis2jCsYueOC6+xlzdFunc84eCvccFZe3yKPTHPu3sT?= =?us-ascii?Q?MkqS+lq8y+ON1IHzuWmVDcxM?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4834.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 045def66-71f3-490c-f4d5-08d9527c1072 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2021 10:31:45.3608 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: zLzheniG6xYM8v7u+PExh6K2dJmDsK4mXPXhDXM99qvTg2dNH054UTmQbKE2BZhwOygMDeH+8C4FIpCxT7pEfA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4321 Subject: Re: [dpdk-dev] [PATCH v2] app/testpmd: fix TX checksum calculation for tunnel 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" Hello Olivier, [:snip:] > > > > Correct. Inner checksum is offloaded and outer computed in software. >=20 > I think this approach is not sane: the value of the outer checksum depend= s on > the inner checksum, so it has to be calculated after. There is a comment = in the > code about this: >=20 > /* Then process outer headers if any. Note that the software > * checksum will be wrong if one of the inner checksums is > * processed in hardware. */ > if (info.is_tunnel =3D=3D 1) { > tx_ol_flags |=3D process_outer_cksums(outer_l3_hdr, &info= , > tx_offloads, > !!(tx_ol_flags & PKT_TX_TCP_SEG)); > } I agree. That computation order led to error in my case. What if the engine could analyze port TX offload options and select=20 processing order according to existing configuration ? =20 > > Consider this example: > > Tunneled packet arrived at port A and being forwarded through port B. > > The packet arrived at port A with correct inner checksums - L3 and L4. > > Port B TX offloads inner L3 only. > > > > process_inner_cksums() sets "ipv4_hdr->hdr_checksum =3D 0;" > unconditionally. > > Inner L3 checksum value will be restored by port B TX checksum > > offload, but when > > process_outer_cksums() runs software calculation on outer L4 it will us= e 0 > and produce wrong result. > > > > Therefore, the patch zeros inner checksum values only before actual > software calculations. >=20 > I better understand your use case, thanks. >=20 > However, with your patch, if the inner L4 checksum is wrong when it arriv= es > on port A, I think it will result in a packet with a wrong outer > L4 checksum and a correct inner L4 checksum. Is it what you expect? >=20 Wrong checksum reflects ongoing issue that must be investigated and fixed. I don't expect forwarding engine to fix wrong checksum because it can hide a real problem. > I don't argue against the patch itself. What you suggest better matches t= he > offload API than what we have today. Can you please send another version > that better explains the use-case? >=20 I posted v3 with updated comment. > One more suggestion, maybe for later. Currently, the csumonly engine can = be > configured to do the checksum in sw or in hw. Maybe we could add a "dont- > touch" option, to keep the value in the packet. Would it help for your us= e- > case? >=20 That's a very good idea. Packets can arrive with pre-calculated correct checksums. Keeping these val= ues can save processing time. [:snip:] Regards, Gregory