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 95ACB43C35; Thu, 29 Feb 2024 10:25:35 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5141C402B4; Thu, 29 Feb 2024 10:25:35 +0100 (CET) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2068.outbound.protection.outlook.com [40.107.93.68]) by mails.dpdk.org (Postfix) with ESMTP id DE395402AC for ; Thu, 29 Feb 2024 10:25:33 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XQmUHyjp8X9GcwREun6NEhdSUuQnyMq1QbctEEHwtHU0By7GhDir4w/UVlp7ubkLaPGD2hc1fYUo+AeBvbtjg0S6RYmOXGELBUpJ5yUQJU1TKPbKZdCtED7bXxBQKDvFONau7rFrP86Pyiq0iMo8QCgzOvq7eURSCcnZ15KL92ojJCRSugzCeppyqGbZ5GDU11WhzABKubj+z51QTyhANvZVyCcnuy5XbM1JGIGZhgrMPcmgUuR3V+Rm0bD0dWhk/LmZo+sYX1v/Jzs9ds2ounLUBCrNhWtybclrNXok+3TNZEpGqfBa7LuMTxq6WGwFzahfRvnVtMFf+Arw0SnOqA== 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=quaJ8DkCAupUARPIWUQM+sq9KVeHeUben88cGGSsFU8=; b=Ms2IG0A0SqhsPy5BWmI/enUq1YofUdEHUhQuVGaiZVzggWoq5KVs6hAAK/HV1tvnHs8zCAHAIjc4bqOKrRCGrcfMeiClG8C7Z/P+mJQsrqxzyHQdq3s2pcfp9nu6Fb0od//qlr1uW3eQBh3oY2+OGNFVJI5KA+PR5myM502uOpB76XdKIVUCIFfOJrIqfIUyql5R4FCKyelPRZyqs80C19PSTmeclbs1RF/Of6EhnmH02ZQbxbafaiBS0Wj2vGNFDFRBh0jafaoclTPzC2FVlZgd/iBuzbWox3lsd8h4V0mShm4ThTcw3t/NuePKnjcrZsWmGEEGkmyknEeYyrKxSg== 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=quaJ8DkCAupUARPIWUQM+sq9KVeHeUben88cGGSsFU8=; b=uwSIoPTF73SlCSOLnb4y2CdVgjU4MfAND7qrXyOuXdFaRAZrAVb/tskc8lEnYX+3tWlJIdozzFbldQDSS/IzYhH4zJrAOsy/6UVwAuDDqb2ltUr7lDJ4/H9Rd5JUh1QhXIpDxTruAevh/E88EpfGvY7AWHELxS/V6kI+P+QvU0o= 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 DM4PR12MB7720.namprd12.prod.outlook.com (2603:10b6:8:100::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7316.39; Thu, 29 Feb 2024 09:25:30 +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; Thu, 29 Feb 2024 09:25:29 +0000 Message-ID: Date: Thu, 29 Feb 2024 09:25:25 +0000 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] net/hns3: fix Rx packet truncation when KEEP CRC enabled 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> Content-Language: en-US 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: <760c70e6-ca2d-4d5e-9a05-809b81d32dd3@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0414.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:189::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_|DM4PR12MB7720:EE_ X-MS-Office365-Filtering-Correlation-Id: c1999293-b703-4730-3bbc-08dc39085edb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: YFLcUyPH6sbCjYT1CXEfZW+TJmlSKpqcSX2RBo7ArcYOKNRkHkRiYTOqNF6kKLksgX+LInK6hwIJZ1iLyMZ7oFdE+g8iVAXlRg/xPoryRm3u8ao2RyI5jyH8Yll77h3ALgyCKyJxv4PiFc+FHzffTAteckCvdv78cd0pI5stdHar5XBGFxj41GTEwoI2JCGUlZOTJyBvvNr+prsRHNK4uGCoNsjwSu/WMHYCKJdjGfEyERlHsOV5HouZv7HGx28OMLVgMRor4H5jXev+Xfcu1e+UQJ4OiqWUR0sqB18Ew4VWxtY+FrDlQ6r6VZsQIa3Qy3quEj0BGy5QfLr34qJ3LKdv5k0f/B1fJRnEFnQ6rskS9pDXnjSLlGipMVT3FKWyZ3yfak/15fRQzYBnwbXYImDGaW30RtxHWJKbKCxql3x/YRAfDlkQIB3er5/tOEbqxBI9KIkuJusQDIr5egMHwtopmpUN5b2mP5gGYN5nteuhS8MBtB1FlrgLG0jt5fUm6OkBQveBk9iYPRXS+cJDsNVqDj7Ketxeflfni12yyQagB0sXeYUMWDi7vOy4bsbf7IowvswRuEyy5WFw2+7jXA== 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?V3JsNmhBZVRBb3F2dWtNdVJHSXRPTzNOa21Ga21jY1NwenZ0V0d2NUhaUTdn?= =?utf-8?B?UTM2SzdpL3dQNk5wcmdrYTR4SURRSnJvcC9Kb3BaNk1PSEVFMDE2MzhDRTlW?= =?utf-8?B?YkRmbGZ2c0tTZE5qSTVLMVJoVHQ2ZUROZDQxWFhBWlQrYndQb2xGaW15Q2E2?= =?utf-8?B?NjR0d1I0K0xuSEtCMTVuaVFIbFc4N1RsNVpVRTdsNTZUNmpTdWtIa1V3ajJn?= =?utf-8?B?YW01UzhZWW9LSlpXMTdPMHE2NW1OOEU1OVF4ZHNJQ2c1RWhWdzVpSHYwZ2g5?= =?utf-8?B?OWszNUkzczk0eU5HNDNwaHViMGwxL3VFbHdVQ0MyZFZIVFZVMzZCZ1dMMmJx?= =?utf-8?B?MVdremtZTUE0TDc4bVgzT1B4RVBWbXRGYW9GVk1oNWIxSy9kMDk3bndJVG5w?= =?utf-8?B?Q1ZyTUpaNUl6NkFwSVpzbXFSdHNzZDZ4cUZncXYwdGh4Mmt4Y1ZuV2pyVndp?= =?utf-8?B?MmhFNno4cG1MQWJhdXZ3Y0JVOWNSNmlzeDhWajI3bHRKbkRLbmVKaXVzTEta?= =?utf-8?B?Ynh3NjB4ZHJubFNna0x1R21jL3BOdU53NlFjS2lYcFpnekdYK0pML2NxNStM?= =?utf-8?B?R3Bwb3ByRCtCdU5EcW54UmlpeVFuTldTNm1jUWpRaTVaL1VPZkFwV2hMZ0lj?= =?utf-8?B?ZlJqN2xiVGlRb0owZllKT09WZ1YzemRGWXFSMTlIRWRGYml3dGpEcVU2M0Y2?= =?utf-8?B?TWxSV3BSa3BwWTVzV3l2MU9KVTdpWVRMcGZheWp4dGkrZVgzMXQySnh4N0tI?= =?utf-8?B?OUJveUdnQVE0L09MbUlNSmpadmJ4cFovVm1ocVpMTGdxMG9Hc21DenFFTlFa?= =?utf-8?B?VmNpQTdBOUxsTG9Db2xQa2FId0ZibkxONmRjVFhjQk1LZ01Na0pvU1p1Qlo5?= =?utf-8?B?WG9iNi9KSTdWVkRNSWVsQVlodmprVHYrVmJ5c1JOSmtQcGQ0aEVNbUd4MUpC?= =?utf-8?B?NVZUVzhFR3l0ODNLZ1JXOE5hdWpGZnBoeVZMYmtFNkY2eExRVURaVXFkbTg4?= =?utf-8?B?MFVxNU5MRzAyTlVhdXBYTkk5Y3BMRnlyUU1HY2FiZmg0OUQyNFBkK3ZiWGcy?= =?utf-8?B?bEdnVlBBSFV6V3AveGRiQTVqdkovVG92aVUzeWlkRndSb1FtaUZsMjV0djNV?= =?utf-8?B?cmcyUkYxWE9UM0s5S20rNmVydFhHUlVzNCsxZHFVQU5aSWIvd0QxcXNtemg2?= =?utf-8?B?VVo4UlNCQ1lVNGw1akJVbGQxMVk2V1VvemxOcWNBcTl0cTNpZXhvejJNa1lQ?= =?utf-8?B?Tk8vcENyTXZRbHlaemhvNEVFRjRFaWRkOVd4RTlKbDdQVDAvMXZjV1c1bjRZ?= =?utf-8?B?Q1U5eGxKUW8vVXM2UTVIKzJySTU0ZkpEeGM2MHgzTWNRblA1WllTOEgvTnBy?= =?utf-8?B?My9hcWo1N3ExVXpycWJnMUJuZEZvRkZxSndyNkJzNEsxYTlBRi92dlNKUUJs?= =?utf-8?B?eHRlcFhnLzZaR3M1MS9pdzl5ZDA3Vk9PbUVIeUtud3FmekdrNldaYlpCQWpy?= =?utf-8?B?TUs0Rjl3SVVwblVLU2M1eEU2eUFxV2J6VWxWbzZOY3pnVnVwOERKVGdrY1hR?= =?utf-8?B?bndVOG1HTXlJQUVsUkNMUkJ2bkFoV05JdmZHNEtVSTExMitZaWVjSG9iNVpO?= =?utf-8?B?V0F4U1p5d01ZTHVPdGRCOFZKWTVsM0w0dEd0TVFmbzY4SGtVMlpFSXZHNjJ3?= =?utf-8?B?ZHd3SHlibHNVNldub1BFOWZJOVVnTVNEdlpIM3FCRU1TaXJBY3YxWnNiWnZy?= =?utf-8?B?WjBnQVFCeUQxT1FKRWZKMEdVUXp2WFlyY3RqZlY2TkpwemRRR1lVUjFKdjRR?= =?utf-8?B?OW9jNXZPUnU1OE5PNUd2OHR6L2sweEc4aWpiSzY5dUxrcHhUT1pVb2FrR0Ri?= =?utf-8?B?dyswTk02Q1JXN2NobTNBb3RYSWhQQW42VE9yYnhYcE4rcWZDV0VXaElKeG9w?= =?utf-8?B?UzhBNXloR0ZUV25MWGlza1pvSnNITExEK0NPYTVqOVNkaXlPemMzZlF6NU5V?= =?utf-8?B?MFIraHN3N1dldlFSZXlrdGRBYUY5REZ6ZGw3dHlndkFBSktVdTVSVUJUdG9R?= =?utf-8?B?WVpmSWxtb0oxT20xaU5uNHV1SDgwaXJYTlZTcDBxRDltT0d4N2tDQmZuUkhK?= =?utf-8?Q?bjSrdMYinjiSbtRsLqfHE6r7V?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: c1999293-b703-4730-3bbc-08dc39085edb X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Feb 2024 09:25:29.5994 (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: EhX/cWbRQbcVQdymhlsdnpy48feom15GHlrBBkiKjrtU/3u9U0v0G66C1ZMeQj7P X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB7720 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 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. > 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.