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 6BC9743BCD; Fri, 1 Mar 2024 12:10:13 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EFA3843381; Fri, 1 Mar 2024 12:10:12 +0100 (CET) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2088.outbound.protection.outlook.com [40.107.237.88]) by mails.dpdk.org (Postfix) with ESMTP id E5446400D5 for ; Fri, 1 Mar 2024 12:10:11 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lcFZ2qYCu42xzfXS7w6zEDKh5VNX467AazIsEJ8lY0U5DkgfprZKg4WVtuXEQjR/33L4zMRWADWvFTqSYIvycudhkm5dFoLSLmffkuH3NG5bc4Jwas7Ae+D5vcAKM+jFPmYjWYQs5RH5Hg9WMOcJk+sFYhQ6yrmD/NRtuxV/YkyL5bH82YMQ9Ky9tSHp0VeVkdj9cR7RrXyLLXW+oV8U9NobgJh4FDI3K7/o93gpw2FZ5BEtECvGNuRZAEdgdfjXr07hpoNHTs8MGDEkPi0Yc2OpA+w4jqMCIrXPK+STa+CBh9iRVqlXqKDuaAczsmYsKaCYMO+gamuJ9YFOCgA/Ww== 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=4gWcpqm0BKD3BL4nth03+CWfua8/AUemeMOrrs54Xw4=; b=cJNzb0CorCj9LwMLQ6qFDX9oSCuoRo8iFxOnl8b5nsEB/JcA4p4+ej8HPQI7vtMUf5JcY2SGJjRZaJ0r2obxYkpSiLtCcBPqeLIM3xIInxcG4707sB/MlI7/IRU8I1VQWEDA1kSj19l24D1HeCubMjbUeWrLMM3KqfGT/Fa6U1VOPRrJSEpSHtixVGfeT9r0mSNu3ks2fr2pXHGJDalNy1Kz96nyz5o58GPUSOBgtDKtdhgMwzFYs6ZC0V5Jk0Ui/sK7PiwJbUSaxnjtF2uZl4gIPLEjyEafxmhPWps2Rz8qpDL2TWJg3PkOtFxPYU6VFbMMangOl5aBz8Hoi72MmA== 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=4gWcpqm0BKD3BL4nth03+CWfua8/AUemeMOrrs54Xw4=; b=pbBoe+y9ZUBE/joe4GlDubstugtQ47+wdFV7X/TKRRvbfnv8vN1c4FjtkJtHZwrq0DpKI/aDkVZvh9ohhPTkjHC3ULsMKNRasP19oohcPKNtimSfH2vsReB/62poeSCLbxR9Ej/DydQIQtoYPuja34hy/Rwff1gkCwJPcUk9EgM= 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 DS0PR12MB9448.namprd12.prod.outlook.com (2603:10b6:8:1bb::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.32; Fri, 1 Mar 2024 11:10:10 +0000 Received: from CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::3ec7:6339:1c14:c529]) by CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::3ec7:6339:1c14:c529%5]) with mapi id 15.20.7316.039; Fri, 1 Mar 2024 11:10:10 +0000 Message-ID: <541e9d04-bed3-47b0-8b11-746f9047e1a0@amd.com> Date: Fri, 1 Mar 2024 11:10:05 +0000 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] net/hns3: fix Rx packet truncation when KEEP CRC enabled Content-Language: en-US To: huangdengdui , Jie Hai , dev@dpdk.org Cc: lihuisong@huawei.com, fengchengwen@huawei.com, liuyonglong@huawei.com References: <20240206011030.2007689-1-haijie1@huawei.com> <11b8feac-4a9e-4d2c-8995-ed492d684750@amd.com> <7438563e-c7b4-6e13-68bf-74ff423546af@huawei.com> <6246e1f8-dcd4-468d-a05d-2e292f6e1714@amd.com> <6c831a66-f916-48d4-68d9-4c3bcfcb4979@huawei.com> <1ec105cf-c8d2-4010-867d-30970c25a2a1@amd.com> <7e376ab0-67a0-4a3c-a528-7928077e7b56@huawei.com> <760c70e6-ca2d-4d5e-9a05-809b81d32dd3@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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0018.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:150::23) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|DS0PR12MB9448:EE_ X-MS-Office365-Filtering-Correlation-Id: 43516a87-4cf1-4c4b-cf22-08dc39e028a8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Ukj8ZCMdXL+DNAYDIOMOIUp+ci5s1ZD1WjTxGW4YFyhmjYF5jPd7At825fkk+3SAbyNgjOIQ8JrzSK6xE8WFRUuY6RWddTpUDjhhXt8l2uP5KKt1hpJLFz6ug4kPSyDXEXjJuVGk9DIta9aryZOdGdA/jKo+IRTmpKQn/RVBwBaj+9aGFdhz+cWZ+41sC3woQugm0cgzrcibRkeb0F9B87z26fvcOuKNpsKkc0LsMQrwvWyEFITYRTnWSexrFXdEPpgqthpM6ztlmUe/R5JeV1B60jMCX4m/7DvzDb5aRhwyyq5I1MvkzVEOzG381GtK9IMHEHo142Z8dwxvWtNEiK6uwRHktRtsMgGrpkHN6K4qHwJPKm1MQpEyTgibBabuGSNRxPfahfNuWdAGYpGONzmL6PF0Ah/kSX9PL3fPOWpnvSVqtdDVGKDxOtEgHrMJXs3qo5WhbMpNL8jImdqz8WRi0iGBeaK/sbjCI0ZL7ESf/efMfRSmo2dTq6OtNV2NW3j3bLHA8WI4I78az2WZCrBS2DU1FtTxIl1doAr8QSIY3lu+B69mkYeLw2Zn3bHTCYW1YrwBGX79FIZ74iC/7g== 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); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NUIvbWJpVDF1MElnKy9WenBEZlhkNnRSdmd1bkdYcEU0MTk0TEhaczZRMGdD?= =?utf-8?B?U3lkVFYzaGhQa3Zhcm9vQ1dsMHJQRTZtaVRpNW9XU1Z0K2NvRjhmeDNSUE9X?= =?utf-8?B?QlVRNGFyVmpZZ3RhMFRucjBKNExPTENwZEkwbTNJcnJrbTV5MnMrMTdUR3Jy?= =?utf-8?B?bm1DNWdBZWt2UVh5dEM1RnhQUkFnOGJQd2lRVjVmS0FuQ2hTU3pPeXlBaGVk?= =?utf-8?B?MCtWS2VMaXhYWXpzdVp4VXJGMzFUK2NacEthTm9UMFRwUmFyWXdQUW5WUUl3?= =?utf-8?B?VXZFVFF2Uzl3eGlhTEJLNys4MzdyVmZLUk5nVS9oVFFYbWhCLzViUVo0Tmwr?= =?utf-8?B?bks3VzdBdE1BUWt0b1FGSXRBV01tcGJ6T1dBc0FrUUdTZ29qRDNZOGFMS254?= =?utf-8?B?TWJQK1RHRVBUU1hNMUtleGFGRXd5YS9zVmQxRHB0ZERScjJzM01KRDNnVGtn?= =?utf-8?B?NktwWTZGcmJMZVRaM0VuMjlMSUhaT1ZmUFdkaENOYytWY3lwcG9vdUlTdWdW?= =?utf-8?B?RjdNOTNtWXp2QzdqVnFUYXBRc2pPZlhVTnNBYXluY2NrY3ExdXFDTC9TMGcv?= =?utf-8?B?WXEzd3MxOWw3MWRPbHJwaXppRU96aWdlcktYMnlxaFRLazlvN0hISFdiZ0dj?= =?utf-8?B?Vk9YRFR2M09zdG9uVHlleElkbmdETWgwaFhyV0F0V3FDNDNGS05tMVNrczJx?= =?utf-8?B?TW9sbzM3VDNTbFlOQWVrejd3ZmozcVN3eVlKbHdNeS9mNHgySEpxUnpEcG5I?= =?utf-8?B?QkdXS21PV2RjN29leCt5Zmljbng0MkcxWTdqYWplNG1uWmFMdVBnM0RQd2pv?= =?utf-8?B?TE5NbWNNL2swWDFHOGhxMDFxQXI3czRxUytUWWN2Unk0NHNSVUVaZThZdnl2?= =?utf-8?B?RDMxUGtCMThOR3ZXOWU0Q095NE9GVHdlMHpvMHY0clVGUkp0RzBLeXE0QnM1?= =?utf-8?B?ZDZqZjRVNFlONFRxczlmQkMyallUN2xDNVhZS29UbXRtZ0xuSnRHQWEwMmxS?= =?utf-8?B?TTNIK0VzaDU1Wm0vZ3R2Rmp1Y0VRMnFqbU4rWW1KM0lvRlZtZ0dCd1FhYmRF?= =?utf-8?B?YUNTK3ZzbEtxWWVGVzNjOGRSbDNxbGlZWlB5WFkxemRSdHBSSlFxNTl6NjI1?= =?utf-8?B?QWxyWjBHeHo5MzlDUlFIS05XUHIrWnJHeWdBcGthZE1KWWhwbk1GcnRic0Fp?= =?utf-8?B?RDJ6L0xndHZvSDJpazJKZDFlcEtkTjFkL09sMmdLZ1liV0xKMWR3MnJGSGtV?= =?utf-8?B?QlFQZTJZSEF4TERkK0VNb1EycHNBNG0yUURScSswaktYOXN5cTR3dXhDWEJS?= =?utf-8?B?bHVXWG5WbjZHc0YyVmRaUTdpN1lBQWZpcUdzME1zYU9FSkJTQTRqQjR4aGFw?= =?utf-8?B?d0pvRGJZWHdOcW56aUpGMzJIWUMyYThyV0l3ZC9yN1ZjdHF4cW9MeWhlV3ho?= =?utf-8?B?YnJERlhLakpxWWUzZUdwNVQ5K2h6T1hqSStYaHJxei9hbXd3ZGVzaVlXVkVi?= =?utf-8?B?UThqbyszYzNmNU9OQVVlQlNyTUJHVWtGUTc4TmwzTFdoVStaQUhXMTMvczZF?= =?utf-8?B?Nzk3QktNVmRnak1aSzVBQU5hMVYvSjdIM2M1ak5NV0lDTC9KVjdWdWVLTG1K?= =?utf-8?B?M1JuYUlZNXB6eEN4RHhmSGhqSWtuTjhoT0FSbWo1S0ZOSG1VY1V3WE4rSFcz?= =?utf-8?B?Wi95RTM3RU9qb2FqZlJQN0V2UGhxV0RxVW1LZ093Tk95eHFKd1UwNnAwVjJ4?= =?utf-8?B?cTNvVnpoRmhOU0IxUTIyWUJzdU4reHFGVGhVeGxSUWFLdFRvS0hvcjM0Mlkz?= =?utf-8?B?dmtRQ3BVamZ6WjdYRDRzLytsZWw5TmJqY0ZzRHRGZHl4bHB6Zi9hZCtpcEQ5?= =?utf-8?B?aW1ibGpBY1oyUDFyVTJYMVV3cFZxMnVRZjRKN2lHR3QwdW1PaWVpeW1hSTVT?= =?utf-8?B?cHRRSXRpdmROcjh1eGJ3cmExMk9DUFlYWE9aSmRkZWlCOXNoMlRTbkNVR2Ni?= =?utf-8?B?L2c5NXlOLzdRMU5nRGx3Vk5WbDlBYVhMSWVKT2gvSFR0aFJWRjB0dTdMVFg4?= =?utf-8?B?Ti9Kb2xBOWVzZ0xBdXRwWFY5TldzMnlsOHVTZ0VhbDZESlFvdlNlbi8wdGdW?= =?utf-8?Q?tcMJrBcBVN5KKEX/QZFuvF8Px?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 43516a87-4cf1-4c4b-cf22-08dc39e028a8 X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Mar 2024 11:10:09.9558 (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: SHKnclwG433GXpXpZiW+xhT3iv4QWuAfIJi2A1u6i67PKQ51FkQkj3oVHDegyQmd X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB9448 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 3/1/2024 6:55 AM, huangdengdui wrote: > > > On 2024/2/29 17:25, Ferruh Yigit wrote: >> On 2/29/2024 3:58 AM, huangdengdui wrote: >>> >>> >>> On 2024/2/28 21:07, Ferruh Yigit wrote: >>>> On 2/28/2024 2:27 AM, huangdengdui wrote: >>>>> >>>>> >>>>> On 2024/2/27 0:43, Ferruh Yigit wrote: >>>>>> On 2/26/2024 3:16 AM, Jie Hai wrote: >>>>>>> On 2024/2/23 21:53, Ferruh Yigit wrote: >>>>>>>> On 2/20/2024 3:58 AM, Jie Hai wrote: >>>>>>>>> Hi, Ferruh, >>>>>>>>> >>>>>>>>> Thanks for your review. >>>>>>>>> >>>>>>>>> On 2024/2/7 22:15, Ferruh Yigit wrote: >>>>>>>>>> On 2/6/2024 1:10 AM, Jie Hai wrote: >>>>>>>>>>> From: Dengdui Huang >>>>>>>>>>> >>>>>>>>>>> When KEEP_CRC offload is enabled, some packets will be truncated and >>>>>>>>>>> the CRC is still be stripped in following cases: >>>>>>>>>>> 1. For HIP08 hardware, the packet type is TCP and the length >>>>>>>>>>>      is less than or equal to 60B. >>>>>>>>>>> 2. For other hardwares, the packet type is IP and the length >>>>>>>>>>>      is less than or equal to 60B. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If a device doesn't support the offload by some packets, it can be >>>>>>>>>> option to disable offload for that device, instead of calculating it in >>>>>>>>>> software and append it. >>>>>>>>> >>>>>>>>> The KEEP CRC feature of hns3 is faulty only in the specific packet >>>>>>>>> type and small packet(<60B) case. >>>>>>>>> What's more, the small ethernet packet is not common. >>>>>>>>> >>>>>>>>>> Unless you have a specific usecase, or requirement to support the >>>>>>>>>> offload. >>>>>>>>> >>>>>>>>> Yes, some users of hns3 are already using this feature. >>>>>>>>> So we cannot drop this offload >>>>>>>>> >>>>>>>>>> <...> >>>>>>>>>> >>>>>>>>>>> @@ -2492,10 +2544,16 @@ hns3_recv_pkts_simple(void *rx_queue, >>>>>>>>>>>                goto pkt_err; >>>>>>>>>>>              rxm->packet_type = hns3_rx_calc_ptype(rxq, l234_info, >>>>>>>>>>> ol_info); >>>>>>>>>>> - >>>>>>>>>>>            if (rxm->packet_type == RTE_PTYPE_L2_ETHER_TIMESYNC) >>>>>>>>>>>                rxm->ol_flags |= RTE_MBUF_F_RX_IEEE1588_PTP; >>>>>>>>>>>    +        if (unlikely(rxq->crc_len > 0)) { >>>>>>>>>>> +            if (hns3_need_recalculate_crc(rxq, rxm)) >>>>>>>>>>> +                hns3_recalculate_crc(rxq, rxm); >>>>>>>>>>> +            rxm->pkt_len -= rxq->crc_len; >>>>>>>>>>> +            rxm->data_len -= rxq->crc_len; >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Removing 'crc_len' from 'mbuf->pkt_len' & 'mbuf->data_len' is >>>>>>>>>> practically same as stripping CRC. >>>>>>>>>> >>>>>>>>>> We don't count CRC length in the statistics, but it should be >>>>>>>>>> accessible >>>>>>>>>> in the payload by the user. >>>>>>>>> Our drivers are behaving exactly as you say. >>>>>>>>> >>>>>>>> >>>>>>>> If so I missed why mbuf 'pkt_len' and 'data_len' reduced by >>>>>>>> 'rxq->crc_len', can you please explain what above lines does? >>>>>>>> >>>>>>>> >>>>>>> @@ -2470,8 +2523,7 @@ hns3_recv_pkts_simple(void *rx_queue, >>>>>>>          rxdp->rx.bd_base_info = 0; >>>>>>> >>>>>>>          rxm->data_off = RTE_PKTMBUF_HEADROOM; >>>>>>> -        rxm->pkt_len = (uint16_t)(rte_le_to_cpu_16(rxd.rx.pkt_len)) - >>>>>>> -                rxq->crc_len; >>>>>>> +        rxm->pkt_len = rte_le_to_cpu_16(rxd.rx.pkt_len); >>>>>>> >>>>>>> In the previous code above, the 'pkt_len' is set to the length obtained >>>>>>> from the BD. the length obtained from the BD already contains CRC length. >>>>>>> But as you said above, the DPDK requires that the length of the mbuf >>>>>>> does not contain CRC length . So we subtract 'rxq->crc_len' from >>>>>>> mbuf'pkt_len' and 'data_len'. This patch doesn't change the logic, it >>>>>>> just moves the code around. >>>>>>> >>>>>> >>>>>> Nope, I am not saying mbuf length shouldn't contain CRC length, indeed >>>>>> it is other way around and this is our confusion. >>>>>> >>>>>> CRC length shouldn't be in the statistics, I mean in received bytes stats. >>>>>> Assume that received packet is 128 bytes and we know it has the CRC, >>>>>> Rx received bytes stat should be 124 (rx_bytes = 128 - CRC = 124) >>>>>> >>>>>> But mbuf->data_len & mbuf->pkt_len should have full frame length, >>>>>> including CRC. >>>>>> >>>>>> As application explicitly requested to KEEP CRC, it will know last 4 >>>>>> bytes are CRC. >>>>>> Anything after 'mbuf->data_len' in the mbuf buffer is not valid, so if >>>>>> you reduce 'mbuf->data_len' by CRC size, application can't know if 4 >>>>>> bytes after 'mbuf->data_len' is valid CRC or not. >>>>>> >>>>> I agree with you. >>>>> >>>>> But the implementation of other PMDs supported KEEP_CRC is like this. >>>>> In addition, there are probably many users that are already using it. >>>>> If we modify it, it may cause applications incompatible. >>>>> >>>>> what do you think? >>>>> >>>> This is documented in the ethdev [1], better to follow the documentation >>>> for all PMDs, can you please highlight the relevant driver code, we can >>>> discuss it with their maintainers. >>>> >>>> Alternatively we can document this additionally in the KEEP_CRC feature >>>> document if it helps for the applications. >>>> >>>> >>>> [1] >>>> https://git.dpdk.org/dpdk/tree/lib/ethdev/rte_ethdev.h?h=v23.11#n257 >>> >>> Currently，this documentation does not describe whether pkt_len and data_len should contain crc_len. >>> >> >> I think it is clear that pkt_len and data_len should contain crc_len, we >> can ask for more comments. > This patch doesn't change the logic for hns3 PMD and the implementation of > other PMDs supported KEEP_CRC is like hns3 PMD. Can we merge this patch first? > If hns3 behaving against the documented behavior, I don't understand why you are pushing for merging this patch, instead of fixing it. Other drivers behavior is something else, not directly related to this patch, but again if you can provide references we can discuss with their maintainers. >> >>> Do you mean that we add this description in the KEEP_CRC feature document >>> and notify all drivers that support KEEP_CRC to follow this documentation? >>> >>> If so, can you merge this patch first? >>> Then we send a RFC to disscuss it with all PMDs maintainer. >>> >> >> Not for drivers, just a suggestion that if we should update feature >> documentation with above information for users. So there is no >> dependency to features document update. >> >> > Sorry I'm more confused. What should we do next? There is already API documentation about KEEP_CRC, I think that is already sufficient for driver developers. I am just brainstorming if updating './doc/guides/nics/features.rst' can help end user, but it is not an action or blocker for this patch. Next step is to update this path.