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 37143432B9; Mon, 6 Nov 2023 11:09:42 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B16D9402BD; Mon, 6 Nov 2023 11:09:41 +0100 (CET) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2041.outbound.protection.outlook.com [40.107.236.41]) by mails.dpdk.org (Postfix) with ESMTP id 8112A402AA for ; Mon, 6 Nov 2023 11:09:39 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XCBHSRcHN9tqaNfdEI3J8Bz6tSCqrtpnfzBDri1XC7hsXIpm8DP2yJRRaem0fObNgTT7hgqX3RBp6pcgLYIJrj0oU0BR6XPcPPBOS1X6uDiVShwIkDy2FcEkCiwt0ubWVxb1sRIYv9SpwB+ZR5wmB9xid/tLRkOmHLzTVZHDK4dCFOTvUkDt+PBKngKWmFv6knYhE00nlelnR2VRqs3K0Yg98uYVJB8weQrsJ8YvezuDZV793U6vb9uXC8xWPRD9o/IMMLwl61tjrqej3v8fd8AfMZPhJZqEEN7Wg68EHwF0JSAxvXz5wd2xIHoa82He2fHHYqCS6oOcSo3UK6gZrQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CYBr+a0XrtCvKJ1GY6JW+MVI/yoUrbcsc343xS73gJA=; b=P8PQdQc+4TS26XmMVaBcdkahNWxyolgfVQ6zWagit+efehwSdz+yJT82dO1EKwo3XJ+utApz8l0YbA48T1ZXtDgNQ1Xso+WvycskEobmVgbl3DkfhhlIkmREi/41i7bbibG/S9+o66eWToHNlB7ptoUlNur7uc+dVL09n39mvf/6MOLlum9I0il05avMzgXa1XhB/4R8C9C4L4y9y/RO3gV4OZlZT59F+X+v7L+MxFAqXF5vO/uJ9K4KeY+FdwR13HnANtyRiS6ire6+aZM1hHX0n+W+yQQY3DSWfAP6RQbA4voCKrJLBcOQaVIYr37fv7yXpIXygUv2EFicd/EQnA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CYBr+a0XrtCvKJ1GY6JW+MVI/yoUrbcsc343xS73gJA=; b=igBEIn3sQoZQbVqTry5QBGWRqUho8Bl2AIfivV7rshGHmZk1HPmoQc6jMe3mEkIsE/uoMPRF7ao1V4OzksE0P4O3gjNLZ2oAnUxPVMFSHDDkQESNRmO8VHR6fMIaA+mmhvGQXLNa8SBifFfZZYmziwyA+uDGmAJKERBX9dohE1k= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Received: from CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) by MN2PR12MB4333.namprd12.prod.outlook.com (2603:10b6:208:1d3::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6954.28; Mon, 6 Nov 2023 10:09:37 +0000 Received: from CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::2569:edb2:670f:816f]) by CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::2569:edb2:670f:816f%6]) with mapi id 15.20.6954.028; Mon, 6 Nov 2023 10:09:37 +0000 Message-ID: <7819d317-c0d6-457c-9c93-5b561fabd242@amd.com> Date: Mon, 6 Nov 2023 10:09:20 +0000 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] app/testpmd: fix UDP cksum error for UFO enable Content-Language: en-US To: "lihuisong (C)" , dev@dpdk.org Cc: thomas@monjalon.net, aman.deep.singh@intel.com, yuying.zhang@intel.com, zhichaox.zeng@intel.com References: <20230728021310.15970-1-lihuisong@huawei.com> <20230802025520.8000-1-lihuisong@huawei.com> <62dbcb50-31b0-41a2-9d83-a53b01abd0a6@amd.com> <2eff5f84-d929-2bf9-a9cd-f1f603eb2090@huawei.com> <5746ebed-ff7d-1c3c-4abc-5de45ea15d10@huawei.com> From: Ferruh Yigit Autocrypt: addr=ferruh.yigit@amd.com; keydata= xsFNBGJDD3EBEAC/M7Tk/DfQSmP1K96vyzdhfSBzlCaGtcxNXorq4fALruqVsD3oi0yfyEz9 4YN8x7py0o9EL8ZdpOX0skc0AMCDAaw033uWhCn0GLMeGRKUbfOAPvL6ecSDvGD7CJIO9j0J eZUvasBgPdM/435PEr9DmC6Ggzdzt8IuG4PoLi5jpFSfcqxZFCCxLUDEo/w0nuguk2FTuYJg B2zEZ4JTBZrw7hIHiFh8D8hr6YA6a5uTofq1tr+l048lbtdFUl8TR0aIExVzE4Z8qKZlcE+9 RQaewjK5Al1jLE4sHdmd3GN+IvgDF3D/fLsi25SKJDeGSdeHkOmaX0qGeM4WKIfU6iARRCiQ N3AmBIxZ/A7UXBKLaOyZ+/i3sE6Wb53nrO4i8+0K2Qwyh6LjTeiJAIjYKN43ppxz3DaI+QwQ vI+uyHr4Gg0Da9EPPz/YyKauSeOZCfCB5gIfICO0j6x0SCl8uQ2nLpjxcZkf0gjcwUzP3h+S 3x6NfDji9YEij0zczW/dcSpGgZ6vsFpPrtnP9ZXy6J53yp0kJtOJoOlkEFFdU2yCZnCDseum CoudmGLZVvS0/DzHDJejq+3kK3FDGktZBOxZIIpal+nFqS7lVgOZc4+huVv3jyhzoAUOEyXA XK5j6o7g8STUY+z33QNnHpdLvecMwuzmvqy0jR54yAbZ64mB9QARAQABzSNGZXJydWggWWln aXQgPGZlcnJ1aC55aWdpdEBhbWQuY29tPsLBlwQTAQgAQQIbAwULCQgHAgYVCgkICwIEFgID AQIeAQIXgAIZARYhBEm7aYjps5XGsPHCElRTPtCKKm/6BQJkdyEEBQkE3meNAAoJEFRTPtCK Km/6UdcP/0/kEp49aIUhkRnQfmKmNVpcBEs4NqceNCWTQlaXdEwL1lxf1L49dsF5Jz1yvWi3 tMtq0Mk1o68mQ7q8iZAzIeLxGQAlievMNE0BzLWPFmuX+ac98ITBqKdnUAn6ig5ezR+jxrAU 58utUszDl16eMabtCu76sINL5izB8zCWcDEUB4UqM8iBSQZ7/a7TSBVS0jVBldAORg1qfFIs cGMPQn/skhy3QqbK3u3Rhc44zRxvzrQJmhY6T1rpeniHSyGOeIYqjpbpnMU5n1VWzQ4NXvAD VDkZ4NDw6CpvF4S2h2Ds7w7GKvT6RRTddrl672IaLcaWRiqBNCPm+eKh4q5/XkOXTgUqYBVg Ors8uS9EbQC/SAcp9VHF9fB+3nadxZm4CLPe5ZDJnSmgu/ea7xjWQYR8ouo2THxqNZtkercc GOxGFxIaLcJIR/XChh9d0LKgc1FfVARTMW8UrPgINVEmVSFmAVSgVfsWIV+NSpG9/e90E4SV gMLPABn1YpJ8ca/IwqovctqDDXfxZOvCPOVWTzQe/ut767W+ctGR1kRkxWcz470SycOcY+PW VRPJd91Af0GdLFkwzZgNzkd6Gyc9XXcv4lwwqBLhWrBhqPYB0aZXIG1E/cVTiRp4dWpFHAFD DcuLldjIw93lCDsIeEDM9rBizGVMWEoeFmqSe7pzGTPXzsFNBGJDD3EBEAC8fBFQHej8qgIG CBzoIEd1cZgPIARlIhRudODXoNDbwA+zJMKtOVwol3Hh1qJ2/yZP11nZsqrP4fyUvMxrwhDe WBWFVDbWHLnqXMnKuUU1vQMujbzgq/4Rb9wSMW5vBL6YxhZng+h71JgS/9nVtzyaTtsOTrJi 6nzFSDx6Wbza2jYvL9rlK0yxJcMEiKwZQ/if4KcOesD0rtxomU/iSEv6DATcJbGXP6T93nPl 90XksijRKAmOwvdu3A8IIlxiSSVRP0lxiHOeR35y6PjHY2usfEDZZOVOfDfhlCVAIBZUZALv VmFOVSTYXeKgYa6Ooaf72+cHM3SgJIbYnevJfFv8YQW0MEAJ/IXE7B1Lk+pHNxwU3VBCrKnA fd/PTvviesuYRkrRD6qqZnINeu3b2DouVGGt2fVcGA38BujCd3p8i7azoGc7A6cgF7z9ETnr ANrbg1/dJyDmkDxOxVrVquTBbxJbDy2HaIe9wyJTEK2Sznpy62DaHVY+gfDQzexBXM10geHC IIUhEnOUYVaq65X3ZDjyAQnNDBQ4uMqSHZk8DpJ22X+T+IMzWzWl+VyU4UZXjkLKPvlqPjJk 1RbKScek5L2GhxHQbPaD76Hx4Jiel0vm2G+4wei8Ay1+0YRFkhySxogU/uQVXHTv63KzQMak oIfnN/V2R0ucarsvMBW+gwARAQABwsF8BBgBCAAmAhsMFiEESbtpiOmzlcaw8cISVFM+0Ioq b/oFAmR3IPsFCQTeZ44ACgkQVFM+0Ioqb/qINhAAtcor9bevHy22HvJvXX17IOpPSklZJAeQ Az43ZEo5kRlJ8mElc2g3RzYCvL/V3fSiIATxIsLq/MDtYhO8AAvklxND/u2zeBd7BkRZTZZX W1V1cM3oTvfx3LOhDu4f2ExQzCGdkzbXTRswSJIe1W0qwsDp+YPekbrsKp1maZArGeu+6FuW honeosIrWS98QJmscEhP8ooyJkLDCCOgEk+mJ/JBjzcJGuYn6+Iy/ApMw/vqiLGL1UWekcTA g18mREHqIR+A3ZvypIufSFB52oIs1zD/uh/MgmL62bY/Cw6M2SxiVxLRsav9TNkF6ZaNQCgn GqifliCEMvEuLZRBOZSYH2A/PfwjYW0Ss0Gyfywmb2IA990gcQsXxuCLG7pAbWaeYazoYYEQ NYmWatZNMAs68ERI2zvrVxdJ/fBWAllIEd0uQ4P05GtAHPdTIDQYp545+TPV7oyF0LfXcsQs SFVZE6igdvkjfYmh+QOrHGZvpWXLTmffVf/AQ81wspzbfxJ7sYM4P8Mg5kKOsaoUdyA/2qVe cMh1CLUHXF1GlofpGbe1lj4KUJVse5g3qwV7i9VrseA8c4VIZewdIjkzAhmmbxl+8rM/LKBH dZUMTzME5PFCXJIZ83qkZQ795MTe2YScp9dIV7fsS5tpDwIs7BZNVM1l3NAdK+DLHqNxKuyO 8Zk= In-Reply-To: <5746ebed-ff7d-1c3c-4abc-5de45ea15d10@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: FR2P281CA0033.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:14::20) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|MN2PR12MB4333:EE_ X-MS-Office365-Filtering-Correlation-Id: 8d4773fe-3899-4ca1-ea00-08dbdeb07b55 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: FZFHOxLbPbfTV6BZ5IDIKChKlhM7C1MRQEWeb7N4YN//6jDISmuHRVyM/dmMlYuaUJmnBAMmuuHetHwdey/9qvDBIQX8RSzP3UNE7flh+UVieduqiYDYp8N6xB9d6jVKfS8SLEKPvd9AYZs2vrjQFnrdqDVt2w3UBpJ/2EqCW/+X0hsSe4+Em4WGtKHzuT79FhFxU7iO44KqY8Smw3n4IruEx8I3UpTABpWDS861ECR8P1C+F65sarktCWQNH/IavPS1EYl6QYupJKVIVVdRicnFVG0Uxk1QaiN6+GfcoNw60WZxo9tCk3/TzZ7bTuQ8NUmA0LDUWtUvnw92Ly/iHu2DyCs4Q36KnmfexTco6dmQg//xjpTj2bPEuk+wgoii78aZbpCSw7b2CyAH4TGRiBbHIoaPgWkw27CrMkIZtHFZ+3KsLhwpsP5ZDCVj4muaMIYS+I/tb10J0VL66Ws2F8dQhafEGHwArIQCTRSqrPbL4jA3rtAfkcmDsuQoZrkmH1jrIH8+ZGY5Ts0vdzSDbPnMLzUJsRfry3Zhr27UZAJR9p/m6UZfROMr0KCpNNg4fXe29WsEE4XKN/XJa77wuTf+jETK9kf+RlCWcWbDRZD0LCfbN0u845OGCwd4KktbxHJJH9XfCxpqk7EDgOkw1zD4/sn28uYFQiUCM/nh9FAvV5/aEueAXJpJrL5lYMJT X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR12MB4294.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(376002)(346002)(39860400002)(136003)(396003)(366004)(230922051799003)(230273577357003)(230173577357003)(451199024)(1800799009)(64100799003)(186009)(26005)(316002)(66556008)(66476007)(66946007)(36756003)(6512007)(6666004)(6506007)(53546011)(2616005)(38100700002)(31696002)(83380400001)(86362001)(6486002)(478600001)(5660300002)(41300700001)(8936002)(8676002)(44832011)(4326008)(2906002)(31686004)(30864003)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bTJIMXVSTG11RkxSL25CdkgwakRnK3IxRXJKRGdBZDE3ZVJsY0tuRGtmRGZm?= =?utf-8?B?OWQ2NjBKRmg3OCsyMEdaeWVNRWNFQjk0T3NpdWJrMUxyWi9GbXBuQ09zcVpE?= =?utf-8?B?aGNCVnU2cTdiRjhmMDBaeEhHT0hEVGRxalo4ZTFBZXlncEp1OHh2Wlp3WjNL?= =?utf-8?B?OElOMUVHWkV6TUgrTHRpb3EyWDRnMS9IdlB2ZlA4ZXY4YXJHNUwydWFOcnY3?= =?utf-8?B?ODVObGg4MFZtRkxsdCtTZzYrRUJUS0hNUnFCT1E5aHduN2h0VWNpbkliY0JM?= =?utf-8?B?N1dSOHA3UlRwNEk3RjlSYVpYb2xCM0s2OWM2QXgrNXpFUC9KMWZJMUZOdlV0?= =?utf-8?B?M08wRDBsWWNqazVkeXd0UEZ0OW45WG5nUEFMOG9sS3IxR2Y0eWZyeDI1WUpC?= =?utf-8?B?WEtudjdieGZlSjZ1TmhBZWprV1JyNzNheGVZVUNoZndqcllnckFKaHVwa1Er?= =?utf-8?B?QWw2Uk5WWi9aK1RjZ1ZzK2hjNVBOcU50cTRTaGhvYTUweHlER0xPZkJWeE00?= =?utf-8?B?aVZ2UGcxdG1FdS9zYkdIQUtsRWZ6SUtkLzNJMm53UHV6UWZTZnp6YkZjMUJS?= =?utf-8?B?amV2V2gwTVM5cWxvY0dyMkhiWTZ5ekhHV0ZUaVdGQ3NCMDlnNGtCUHo0clJ4?= =?utf-8?B?ZTE1YkNDVTR5NmxLSVZ0bjFKdFBpdys1OXRhMXZzUC8vekNrajhsbTRKWTlq?= =?utf-8?B?TUpGenJGVkU2YzJjUVdvYW1ORExTTXJxaGlQZVNBeHlQdjZmcm42SW1uakx0?= =?utf-8?B?RGVBRmRyaXlDU2RnUVJMaHdCSllkYktBdURVL2wxa0hoL0Fpb0ZDelBtZnln?= =?utf-8?B?UzY2ZG5SVGc0c3dlZWdzSFlMZnpEWk1rQ2hlUTlCUVhYN0w2bVQyV3d1Nk1s?= =?utf-8?B?ekdRTWJmVDkyM3crQXhXZXZDY0pmcmlZTS9vVVR5VU1BV1ZObEZyWHpMZExS?= =?utf-8?B?Mm81VWdyRGE3QnV2Q3ZjVVNWQzE2Q2xkeldhRDNBZ1E5TXJrdjhGc0lWWDRF?= =?utf-8?B?SUtsNG9sanpIRFlGZGRXSDB5VldzUndqcVBycytoWXhCVGF5eW1lRFgzckxW?= =?utf-8?B?QkRSSy9SdzFQV1AxZXV1ZmVrcC82U2RVZjVTYk1DbnhOMEcrMHFDbWZSUzl1?= =?utf-8?B?ZG1jNG1RN0luRS9LU1hCbll4Wm1TUkZsVEhJNjNXZGlwVy9wQzVLV2trZW9O?= =?utf-8?B?V3JaODVVcXR6NkFnenllUUw3Y0YrVE5vTGVMNHBUWk11UG9CM0cxSkhBSk1V?= =?utf-8?B?SnJveFh4RUgyMGZZVFFoU1cvQVMvdUhzZWFNTWRJMEcrYnpYNzZRTFJteGsr?= =?utf-8?B?OG9CU3VOWnVLRmsyUUxnNWlCRlRqdXRTNDF4SkNoeFM0bm9XdHVJVTNGaS90?= =?utf-8?B?NHZiM09nMU5WNkNKS3RieUJxYjVZMTc5bXlUSW9wYmFzMWR0cC9XejFNT1I4?= =?utf-8?B?NWNYalR5cE9LaUFTZ2RHRkVFbWs2YmVYak9qN0ZaMm5PTi9RVGcrbjdJajIx?= =?utf-8?B?RUFYNjZRUEdxSG9YZ01XdHcra0taQzFQSXdQeXB6dlpHWitmQXQ3S0FiL0Jm?= =?utf-8?B?YW1jSkNDS1VneGtxNmFzdkFxcGJxRXFuOGpTTHd1eVpwaHZqSmxCbzBvUDZy?= =?utf-8?B?R1JSQ2tLcnhlNHdXbUFkTEpuZ0ZKZHcxRzIxVVBsbUp0aVNiQWphejFiYXgv?= =?utf-8?B?aUJ4MWNwTjAzc1VVZ1NLT1g5R25HRlNETlVQbURHU3VuMEdtVTM5cVpQYyta?= =?utf-8?B?V0gycjk2b0lrOFlMdjZCeEREVU96OEdibGthRFJYMDhOc01qTUg2NStuT3Rr?= =?utf-8?B?MjNaR3h5bjhuUUFFT3hlejVsSzBaeTZWUUdLMkFWbnk2S3JZb3Q4VFpic1Bk?= =?utf-8?B?UklLV0hERGxEN2prNGFVcmZxWlZWR3JxcHYzNTZldmIwRjNOVVVqWGxJTmdx?= =?utf-8?B?RW9pNTkxd1VCbzJxNlZ5QjRNb0lTSk1wUkg0S3FKZjlJRjlPZzBQYTdaMXVB?= =?utf-8?B?YjVQMk1Eam8vM2NlL3M2cThvd2x6bTlGWjhxd0l0bGQvVjV1NWhLNFJOMmo2?= =?utf-8?B?OFdHOWJ0TUVoK2pacmtxTWlXcWNqKzRzQno5M1NtYnY3VzFBdm5RcUpRZ1d0?= =?utf-8?Q?KBaI=3D?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8d4773fe-3899-4ca1-ea00-08dbdeb07b55 X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Nov 2023 10:09:37.0298 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: qF4ddpSaZNKL1Zvxmyd9i3q+FYwmwqAH4DSOntbM4oFZSuRZ/W0/ofhwvaGg4ew/ X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4333 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 On 11/6/2023 4:13 AM, lihuisong (C) wrote: > > 在 2023/11/3 18:42, Ferruh Yigit 写道: >> On 11/3/2023 9:09 AM, lihuisong (C) wrote: >>> Hi Ferruh, >>> >>> Thanks for you review. >>> >>> >>> 在 2023/11/3 9:31, Ferruh Yigit 写道: >>>> On 8/2/2023 3:55 AM, Huisong Li wrote: >>>>> The command "tso set " is used to enable UFO, >>>>> please >>>>> see commit ce8e6e742807 ("app/testpmd: support UFO in checksum >>>>> engine") >>>>> >>>>> The above patch configures the RTE_MBUF_F_TX_UDP_SEG to enable UFO >>>>> only if >>>>> tso_segsz is set. >>>>> >>>> "The above patch sets the RTE_MBUF_F_TX_UDP_SEG in mbuf ol_flags, only >>>> by checking if 'tso_segsz' is set, but missing check if UFO offload >>>> (RTE_ETH_TX_OFFLOAD_UDP_TSO) supported by device." >>> Ack >>>> >>>>> Then tx_prepare() may call rte_net_intel_cksum_prepare() >>>>> to compute pseudo header checksum (because some PMDs may supports >>>>> TSO). >>>>> >>>> Not sure what do you mean by '(because some PMDs may supports TSO)'? >>>> >>>> Do you mean something like following: >>>> "RTE_MBUF_F_TX_UDP_SEG flag causes driver that supports TSO/UFO to >>>> compute pseudo header checksum." >>> Ack >>>> >>>>> As a result, if the peer sends UDP packets, all packets with UDP >>>>> checksum >>>>> error are received for the PMDs only supported TSO. >>>>> >>>> "As a result, if device only supports TSO, but not UFO, UDP packet >>>> checksum will be wrong." >>> Ack >>>> >>>>> So enabling UFO also depends on if driver has >>>>> RTE_ETH_TX_OFFLOAD_UDP_TSO >>>>> capability. Similarly, TSO also need to do like this. >>>>> >>>>> In addition, this patch also fixes cmd_tso_set_parsed() for UFO to >>>>> make >>>>> it better to support TSO and UFO. >>>>> >>>>> Fixes: ce8e6e742807 ("app/testpmd: support UFO in checksum engine") >>>>> >>>>> Signed-off-by: Huisong Li >>>>> --- >>>>>    v2: add handle for tunnel TSO offload in process_inner_cksums >>>>> >>>>> --- >>>>>    app/test-pmd/cmdline.c  | 47 >>>>> +++++++++++++++++++++-------------------- >>>>>    app/test-pmd/csumonly.c | 11 ++++++++-- >>>>>    2 files changed, 33 insertions(+), 25 deletions(-) >>>>> >>>>> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c >>>>> index 0d0723f659..8be593d405 100644 >>>>> --- a/app/test-pmd/cmdline.c >>>>> +++ b/app/test-pmd/cmdline.c >>>>> @@ -4906,6 +4906,7 @@ cmd_tso_set_parsed(void *parsed_result, >>>>>    { >>>>>        struct cmd_tso_set_result *res = parsed_result; >>>>>        struct rte_eth_dev_info dev_info; >>>>> +    uint64_t offloads; >>>>>        int ret; >>>>>          if (port_id_is_invalid(res->port_id, ENABLED_WARN)) >>>>> @@ -4922,37 +4923,37 @@ cmd_tso_set_parsed(void *parsed_result, >>>>>        if (ret != 0) >>>>>            return; >>>>>    -    if ((ports[res->port_id].tso_segsz != 0) && >>>>> -        (dev_info.tx_offload_capa & RTE_ETH_TX_OFFLOAD_TCP_TSO) == >>>>> 0) { >>>>> -        fprintf(stderr, "Error: TSO is not supported by port %d\n", >>>>> -            res->port_id); >>>>> -        return; >>>>> +    if (ports[res->port_id].tso_segsz != 0) { >>>>> +        if ((dev_info.tx_offload_capa & (RTE_ETH_TX_OFFLOAD_TCP_TSO | >>>>> +                    RTE_ETH_TX_OFFLOAD_UDP_TSO)) == 0) { >>>>> +            fprintf(stderr, "Error: both TSO and UFO are not >>>>> supported by port %d\n", >>>>> +                res->port_id); >>>>> +            return; >>>>> +        } >>>>> +        /* display warnings if configuration is not supported by the >>>>> NIC */ >>>>> +        if ((dev_info.tx_offload_capa & RTE_ETH_TX_OFFLOAD_TCP_TSO) >>>>> == 0) >>>>> +            fprintf(stderr, "Warning: port %d doesn't support TSO\n", >>>>> +                res->port_id); >>>>> +        if ((dev_info.tx_offload_capa & RTE_ETH_TX_OFFLOAD_UDP_TSO) >>>>> == 0) >>>>> +            fprintf(stderr, "Warning: port %d doesn't support UFO\n", >>>>> +                res->port_id); >>>>> >>>> Requesting TSO/UFO by setting 'tso_segsz', but device capability >>>> missing >>>> is an error case, so OK to have first message. >>>> >>>> But only supporting TSO or UFO is not an error case, not sure about >>>> logging this. But even it is logged, I think it shouldn't be to stderr >>>> or it should say "Warning: ", a regular logging can be done. >>> All right, will fix it in next version. >>>> >>>>>        } >>>>>          if (ports[res->port_id].tso_segsz == 0) { >>>>>            ports[res->port_id].dev_conf.txmode.offloads &= >>>>> -                        ~RTE_ETH_TX_OFFLOAD_TCP_TSO; >>>>> -        printf("TSO for non-tunneled packets is disabled\n"); >>>>> +            ~(RTE_ETH_TX_OFFLOAD_TCP_TSO | >>>>> RTE_ETH_TX_OFFLOAD_UDP_TSO); >>>>> +        printf("TSO and UFO for non-tunneled packets is disabled\n"); >>>>>        } else { >>>>> -        ports[res->port_id].dev_conf.txmode.offloads |= >>>>> -                        RTE_ETH_TX_OFFLOAD_TCP_TSO; >>>>> -        printf("TSO segment size for non-tunneled packets is %d\n", >>>>> +        offloads = (dev_info.tx_offload_capa & >>>>> RTE_ETH_TX_OFFLOAD_TCP_TSO) ? >>>>> +                    RTE_ETH_TX_OFFLOAD_TCP_TSO : 0; >>>>> +        offloads |= (dev_info.tx_offload_capa & >>>>> RTE_ETH_TX_OFFLOAD_UDP_TSO) ? >>>>> +                    RTE_ETH_TX_OFFLOAD_UDP_TSO : 0; >>>>> +        ports[res->port_id].dev_conf.txmode.offloads |= offloads; >>>>> +        printf("segment size for non-tunneled packets is %d\n", >>>>>                ports[res->port_id].tso_segsz); >>>>>        } >>>>> -    cmd_config_queue_tx_offloads(&ports[res->port_id]); >>>>> - >>>>> -    /* display warnings if configuration is not supported by the >>>>> NIC */ >>>>> -    ret = eth_dev_info_get_print_err(res->port_id, &dev_info); >>>>> -    if (ret != 0) >>>>> -        return; >>>>> - >>>>> -    if ((ports[res->port_id].tso_segsz != 0) && >>>>> -        (dev_info.tx_offload_capa & RTE_ETH_TX_OFFLOAD_TCP_TSO) == >>>>> 0) { >>>>> -        fprintf(stderr, >>>>> -            "Warning: TSO enabled but not supported by port %d\n", >>>>> -            res->port_id); >>>>> -    } >>>>>    >>>> Above is redundant check, and introduced with commit [1], I assume by >>>> mistake. >>> Yes, it is a redundant check indeed. >>> This check is introduced in the first patch[1]. But the patch [2] add >>> offload capabilities check but don't delete the old check. >>> >>> >>> [1] Fixes: b51c47536a9e ("app/testpmd: support TSO in checksum forward >>> engine") >>> [2] Fixes: 3926dd2b6668 ("app/testpmd: enforce offload capabilities >>> check") >>>> Since removing above check is not related to UFO, what do you >>>> think to separate it to its own patch? >>> ok, will separate it from this patch. >>>> [1] >>>> Fixes: 3926dd2b6668 ("app/testpmd: enforce offload capabilities check") >>>> >>>>> +    cmd_config_queue_tx_offloads(&ports[res->port_id]); >>>>>        cmd_reconfig_device_queue(res->port_id, 1, 1); >>>>>    } >>>>>    diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c >>>>> index c103e54111..21210aff43 100644 >>>>> --- a/app/test-pmd/csumonly.c >>>>> +++ b/app/test-pmd/csumonly.c >>>>> @@ -466,6 +466,12 @@ process_inner_cksums(void *l3_hdr, const struct >>>>> testpmd_offload_info *info, >>>>>        uint64_t ol_flags = 0; >>>>>        uint32_t max_pkt_len, tso_segsz = 0; >>>>>        uint16_t l4_off; >>>>> +    uint64_t all_tunnel_tso = RTE_ETH_TX_OFFLOAD_VXLAN_TNL_TSO | >>>>> +                RTE_ETH_TX_OFFLOAD_GRE_TNL_TSO | >>>>> +                RTE_ETH_TX_OFFLOAD_IPIP_TNL_TSO | >>>>> +                RTE_ETH_TX_OFFLOAD_GENEVE_TNL_TSO | >>>>> +                RTE_ETH_TX_OFFLOAD_IP_TNL_TSO | >>>>> +                RTE_ETH_TX_OFFLOAD_UDP_TNL_TSO; >>>>>          /* ensure packet is large enough to require tso */ >>>>>        if (!info->is_tunnel) { >>>>> @@ -505,7 +511,7 @@ process_inner_cksums(void *l3_hdr, const struct >>>>> testpmd_offload_info *info, >>>>>            udp_hdr = (struct rte_udp_hdr *)((char *)l3_hdr + >>>>> info->l3_len); >>>>>            /* do not recalculate udp cksum if it was 0 */ >>>>>            if (udp_hdr->dgram_cksum != 0) { >>>>> -            if (tso_segsz) >>>>> +            if (tso_segsz && (tx_offloads & >>>>> RTE_ETH_TX_OFFLOAD_UDP_TSO)) >>>>>                    ol_flags |= RTE_MBUF_F_TX_UDP_SEG; >>>>>                else if (tx_offloads & RTE_ETH_TX_OFFLOAD_UDP_CKSUM) { >>>>>                    ol_flags |= RTE_MBUF_F_TX_UDP_CKSUM; >>>>> @@ -528,7 +534,8 @@ process_inner_cksums(void *l3_hdr, const struct >>>>> testpmd_offload_info *info, >>>>>    #endif >>>>>        } else if (info->l4_proto == IPPROTO_TCP) { >>>>>            tcp_hdr = (struct rte_tcp_hdr *)((char *)l3_hdr + >>>>> info->l3_len); >>>>> -        if (tso_segsz) >>>>> +        if (tso_segsz && >>>>> +            (tx_offloads & (RTE_ETH_TX_OFFLOAD_TCP_TSO | >>>>> all_tunnel_tso))) >>>>> >>>> Should we check 'all_tunnel_tso', and why they are checked only for >>>> TCP? >>> Yes, this patch is just for TCP_TSO and UDP_TSO. >>> But here is necessary for tunnel_tso, or this doesn't set >>> 'RTE_MBUF_F_TX_TCP_SEG' flag for tunnel tso. >>> >> Lets say 'RTE_ETH_TX_OFFLOAD_UDP_TNL_TSO' is requested, but >> 'RTE_ETH_TX_OFFLOAD_TCP_TSO' is not requested, should we still set the >> 'RTE_MBUF_F_TX_TCP_SEG' flag? > Yes, RTE_MBUF_F_TX_TCP_SEG flag still should be set for tunnel tso. > Driver compute pseudo header checksum and fill hw descriptor based on > this flag. >> >> I am not really clear how to handle tunnel TSO offloads, but considering >> previous implementation was only relying on 'tso_segsz', continue with >> all TSO offload will be similar to previous implementation, so OK to >> have it. > Yes >> >> And with same logic, should we add 'all_tunnel_tso' check to the UDP >> case? > I didn't see some offloads about UDP_TSO for tunnel packet. > And testpmd just support a command (please see > cmd_tunnel_tso_set_parsed) to set these tunnel tso offloads this patch > mentioned. >> >> >> And agree that setting other tunnel related mbuf flags is out of scope >> for this patch, but probably that part is missing in this code, and only > What specific thing is missing in this code? > I don't mean this patch, but existing code. It doesn't set 'RTE_MBUF_F_TX_TUNNEL_UDP' or 'RTE_MBUF_F_TX_TUNNEL_IP' mbuf flags when relevant TSO offload requested. >> a few drivers support these flags anyway. >> >>>> As far as I can see some tunnel TSO offloads should case setting >>>> relevant mbuf flags, like RTE_MBUF_F_TX_TUNNEL_UDP or >>>> RTE_ETH_TX_OFFLOAD_IP_TNL_TSO. >>>> >>>> With above check, if RTE_ETH_TX_OFFLOAD_TCP_TSO  not set but only >>>> RTE_ETH_TX_OFFLOAD_UDP_TNL_TSO set, we still set >>>> 'RTE_MBUF_F_TX_TCP_SEG' >>>> flag but not 'RTE_MBUF_F_TX_TUNNEL_UDP' flag. >>> At least here didn't change the original behavior for tunnel tso. >>> I'm not still clear how to set these flag for tunnel tso. >>> But I can ensure that 'RTE_MBUF_F_TX_TCP_SEG' flag is must for tunnel >>> tso. >>>> I assume intention is to be close to previous implementation, where >>>> only >>>> tso_segsz checked, and cover as much as possible TSO offload requests, >>>> but not sure if this is accurate with expected usage. >>> we may need to do something for tunnel tso command as this patch did. >>> I will take a look at it after this patch. >>>>>                ol_flags |= RTE_MBUF_F_TX_TCP_SEG; >>>>>            else if (tx_offloads & RTE_ETH_TX_OFFLOAD_TCP_CKSUM) { >>>>>                ol_flags |= RTE_MBUF_F_TX_TCP_CKSUM; >>>> . >> .