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 027C1A0548; Wed, 12 Oct 2022 10:24:02 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id ADA2842D6E; Wed, 12 Oct 2022 10:24:01 +0200 (CEST) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2066.outbound.protection.outlook.com [40.107.223.66]) by mails.dpdk.org (Postfix) with ESMTP id BA7C54281B for ; Wed, 12 Oct 2022 10:23:59 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QBwLLOwUzRs+80CLXJi16ksqnP5rdDxxzYMGMx+rXi01w493xw1iVkh2o3D2zZY6xL5T+PffyP8/c1nnVTZ5I0+g4rZ5hSudY9aN6avJueNzyDL6GvzdjV1/dZFb25GAj7I1CjhwBM23IJqnZFfNuVanNnbm1XR6oe4a4ioO/1G7ngRllwxE6zJ0VmQiHPv6PUrqrBY8zM7HTvItvCEGHgr3uU2YBQfh2wS1rrYYnfJSorVsLKXawBpRThgWFIyo4hPZ4urq1HuHOYwffw1qa8e5X33crn86oGpzag3pSNu7gBExt1Ooy0C+aBJ8cJsdlI567BjzzDi9tkBfPNnWKg== 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=33DEgmd8nC6jnf2K5YMgXfw+Wtxo/HKtoMzNI2l72yk=; b=GM8ww7oiaobVvKyUly7ltB2S5aw80xNDcBZeMPzX4h0Tl/wERbDnA8Nu4Kp4eS62B63hoqKqvawr1pOIIcyHI+rK7X1PubMf9ZaymSJ6UFJvR1KFFvH54K1EPOhKswaqYXqJm1D/5JD2TGWuxptabro5Zw+ml3i8VvpAwj6lmDNDBz93qwpONRAXaoQsGJ2+xJ/0v1KyuEefVCJUa9y8e2d3nMrXEl3dkUm/X/aW3+IjewbOjQ37475l9+QMOn1WOVQL4jFTu0jjvUnZSyBs2Bpe2QTKKpXJE/8dU3RVfEoMgHQGVsSrnsRcs3rXlctpnT2R8K6GF/ASbkJL1vUHLw== 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=33DEgmd8nC6jnf2K5YMgXfw+Wtxo/HKtoMzNI2l72yk=; b=qNSfySxyhkLuu1hUvwcELNKNh1y3CxpoiE/vVfM1m+4HiiNwPjvq5eSM0Af9z2SyNC9g/qLg3Sq1bA0ABJoXfGXOUr2Rr0yQbe3VwtoOdJ58u1Fxh0cq0RLFsXLfAReg5TcBrfDqnFJa6csYXwxLAAsGFPS7LELObtCwyBOoD8E= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Received: from DM6PR12MB4297.namprd12.prod.outlook.com (2603:10b6:5:211::20) by BY5PR12MB4241.namprd12.prod.outlook.com (2603:10b6:a03:20c::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5709.21; Wed, 12 Oct 2022 08:21:22 +0000 Received: from DM6PR12MB4297.namprd12.prod.outlook.com ([fe80::b9fd:e732:4585:6b25]) by DM6PR12MB4297.namprd12.prod.outlook.com ([fe80::b9fd:e732:4585:6b25%7]) with mapi id 15.20.5676.036; Wed, 12 Oct 2022 08:21:22 +0000 Message-ID: <71cf8172-1000-9e6b-e7f3-9e4850b6615c@amd.com> Date: Wed, 12 Oct 2022 09:21:18 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.2 Subject: Re: CRC offload from application's POV Content-Language: en-US To: "Wu, Wenjun1" , Viacheslav Galaktionov , "Su, Simei" Cc: Denis Pryazhennikov , "dev@dpdk.org" References: <11b33bf3-413a-6955-423a-cc47a73e2202@arknetworks.am> <103627bd-d704-84a2-9f3e-5e4a7341e6a7@amd.com> <2f221574-ac04-2931-275b-e758669e0bef@arknetworks.am> <6e1eb50c-8633-a4b1-e18a-84b525074e32@amd.com> <5e9224e3-7d38-9699-fc69-83d4dd9ab3ae@amd.com> From: Ferruh Yigit In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0099.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2bc::20) To DM6PR12MB4297.namprd12.prod.outlook.com (2603:10b6:5:211::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM6PR12MB4297:EE_|BY5PR12MB4241:EE_ X-MS-Office365-Filtering-Correlation-Id: d8fd11a3-eef8-476a-88f4-08daac2abef3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: R0IFeOjBm0J1icfhcJAtl8OM8hUpXdxCjYy98GCROiC1m8pDOfRjaSBviQPE2oUD3mpCcjQS1PhLlEaR1JuvkM4CnZkGZ0jFfciLL+wIepd3Az8irUlg03Dx9L97QyVwUn0h3s/qSF1qxcUR/ciHqwSBI/POA8rPLQfXI6CkqW4GH2/rpuxJXiY9H4PBYzR/k1lXVpIxeTXhI3Xk1RFu2y3T9J9chhFJXRFFp06mfsa/x3WchquEAFfIPG+bDMaec5ScVHkl+2p5ul6SFYg4I2snd1yBAPgn7soFacC4/kCDT8et60l9Yazl1a7YBoFggpL1Kd4TKdqU3u6xJV0Dwk71EpuR9cKzRiQvrQzFVhkpHA07b/hBUSHr0a9awOldlyDovPP7JB3aHSEUlDjbpVHlY6SIUEGnoU78zwwI7JOpLd1rqiNJPcsteqQcMg8XirLtMM4EJLTG5POC6JDRDUgeppmlX2cYeyCXZsQra2j7DUsccMRwKNgdGgXaw/3GB/5WIAaw20zGg6ZdT3o6w8snjQDfnCjNZM9VFQdYJANsVvwJ5FTGnmoK+6ijzPbOoMJg8RPb/9YBEAyTB2803HFod+9n40hfx3K+9Jcy2FiKtBJRQoF6wA0/4Yxt2rYdkqdrd7S6c3k5FCoF1i3eqP1mxuKay9zmvJg82vU6oDf24fHgPm97TsoZk5EnoBzFGc7JtdA4n4UJplH+Ha9kA5NjhFhIHctdsVpFfXks1usmHpDUz3oE3gfvmgaVPcinxfV3MbYkmve0Lk0til2B3kdKo0uL3ouDrTxy8kGa+U4= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR12MB4297.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(4636009)(376002)(39860400002)(366004)(396003)(346002)(136003)(451199015)(6666004)(6506007)(66946007)(66556008)(2616005)(186003)(83380400001)(2906002)(66476007)(26005)(53546011)(31696002)(6512007)(86362001)(110136005)(478600001)(54906003)(44832011)(6486002)(316002)(5660300002)(38100700002)(8936002)(41300700001)(4326008)(8676002)(36756003)(31686004)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TXgwSCtZUGc4R1BFVDJFcVdrZ3B2NjJ5YXRGOENKSzlIVCt2Q2JNdDJzNzFv?= =?utf-8?B?blFFRlk1ZE5jVWg5bUtRa2ZESzY2eW9wbVI0U2ZhdExVUU5Kdjc0bU1CZUFp?= =?utf-8?B?eldrZHR5enRKOGZtTGxGdDVmb1crTk91c1JkeXF4TW55RWRsTEtGTml1ZDZr?= =?utf-8?B?Sm1jVkUzNllJRUdNcXB5SDV1U2lnQjNLNUptcXFQSDhnMDZNRVQ0MnVvRFhv?= =?utf-8?B?WFNoVm44OUJQNEVnenRRcEdnWWNTWXE1dkFML1k0MVZFaVBrVzIyNnl5VVgr?= =?utf-8?B?QTEyckdkNi90TTZUVGRsaTdkODhNYzQrUHZ3TFBzS2JzdGV0c2ZwYkRsME5U?= =?utf-8?B?NzhjL3IzWUI4NHczbWNpU2Qzd21HeDZHZGdZcTM4bWdrL1VZVVpHaWtPLy9h?= =?utf-8?B?K2IzRmhHK25nejJmanlHVzlGajBMQmdCQlordjVUamdNQklKckhOUDNHWTMw?= =?utf-8?B?eHFuU3RqbFlmOGpCZEx6MnNPT0RUYlpPUnFpRDVaYmt2TjlUZWdaL1pEYkMx?= =?utf-8?B?UisxZ2RMQWNleXFhMlRIZ293RUZubkxyOUgvSkhCdTFLamw5dkY4d0VQUHN5?= =?utf-8?B?S2IrRmlSVjRvcng4aURyN1VlWk9nbEJkcFp1UFdkUlZJZkZXaWNxMVMwMFNO?= =?utf-8?B?S29QNGFRcUhIUGd4ZGs5RjVEdjQzTnZtYkRieUpGazg3VXZDUDRVT2pkZzBV?= =?utf-8?B?cjBBMW5hUjY0RnFPVk5hanRjdzlROUo4L05BN1FkaXdSeTRTYmxpaUQxcXlO?= =?utf-8?B?aXd0c3lCcUEzR2JJU1E1WWh2NC93SXR4ZkdxaWtGUk5sOThTZndZNXhMTnVu?= =?utf-8?B?dzNPcEpKU2xIVnI5Qjg3VWlQeit6TFlCeldpdmJNSnYrWnpkMW1hOEhZOVZG?= =?utf-8?B?QTlkSHdadmMwajZjR3hyZU5IWkN6bSt5bXY0TzNzdFkyQ1J5NUtqTVlydXk0?= =?utf-8?B?S09LazJrWG1xQ3pmejZMRXNKZzhsYituTWpuVTlzN3JjUnZXYTNCeHFYbG9p?= =?utf-8?B?bUlyZTR4NEJiUU9hdzlnZ0lKSS9OT2NrNlRPVHhkQ1lRTG95M3RuRDN1UW9y?= =?utf-8?B?UFg5SW9SYmNCVDlzSlhieXZCUHJCV2dYcit3d3o3UkJZdUZ3Z0x2NE1ucGQw?= =?utf-8?B?a1hUZnowbHdqZXlZSk84TzQrMitSc3VZYTZnY1l3b0xaU0FRRmo1YTV0ekJF?= =?utf-8?B?MUpodG5zRGhFcjNWOFBGeVVrRGM0cXpPRDRheXlLV0dKYnVFNWhES3hGKzk1?= =?utf-8?B?NFNQc0R3aHpoZnA0cG1JVU45MEdnelkrMEF2MDk2Z0cxSVpYYlVKOFN6MWZS?= =?utf-8?B?L0R2c1NTQ1ZVWnUyeUZ0TDl3WGoyY2NWelFaOVptTUMrY2VIUDFzK2daZHY0?= =?utf-8?B?TDR6WGtpb1UrZmtzZmV5V1pBNTZOOGd3dzNPaVdLTGtub1UyZUFIcmorQ0Vh?= =?utf-8?B?bml2OThUd2lqYWtNU09QeWpKQVZKYUxTQng1N2JVZlFGcG5HQUU4a2J5WjBG?= =?utf-8?B?MVNITE8valJzOHBDWXEweWdkVG5Rbmt6RGN4T0FXR1FpMzIvMDBpTjRzRTc0?= =?utf-8?B?MXpTdXdoU1k1clFMd1dFaFhOV0xLUG03RDhhOW9UOG5ncmhqeVRVSHk0Qkpi?= =?utf-8?B?SEZra2RZOWw0YUxoeVlkSmpHdmJYSysxbnhnVXExMGhya1hjK0xEN3dOdCt3?= =?utf-8?B?WU80WEdoV3ZhQWJTQTNFaFg3Myt1VWNOSGRVczJpVklSa0kySUZwQUx3UWpT?= =?utf-8?B?bHBKb25zWGlpbk9ya0QyVWErQnVwUWRkU2RqSDZCQW5KWUp6RWdzZ0c0aEtD?= =?utf-8?B?Rno0aFpjMnVRT0o5Y2ZYRGM2YmFZWTBMS1U4Z2Znc21BMVlpNUFnei96MnVx?= =?utf-8?B?R1pBcHVzYWxGcndIRmZlOGFxL09KRk9GYVJxT1M0cTF4clR1NnQwSnQxbVVO?= =?utf-8?B?K1htYTU3Y08rZUU1cWNqMDVzVlFBbC9mV1VKTEU2V3BBbDdkcjFnTkpqZnJU?= =?utf-8?B?SWpNRlBRdGlpeDFXVVFtTWgyb05SQldzYk1LaUFxL05RN2d3SzZsVDZ0cGwz?= =?utf-8?B?V29yL0RlUzhDbE5zbTlpcCt6RXV1YnNBV1dPWUY0QkpmZDhuTVUwWi9MdWRR?= =?utf-8?Q?U5qYmLGCRvRdlppNMuWt8YEcE?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: d8fd11a3-eef8-476a-88f4-08daac2abef3 X-MS-Exchange-CrossTenant-AuthSource: DM6PR12MB4297.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Oct 2022 08:21:22.0457 (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: Cxz/DECdzqlYMbi4RObWB29yqitLWH8pDQiWiUpMICOGX9j1ogNygaBgZetq9sSg X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4241 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 10/12/2022 9:18 AM, Wu, Wenjun1 wrote: > > >> -----Original Message----- >> From: Ferruh Yigit >> Sent: Wednesday, October 12, 2022 4:07 PM >> To: Wu, Wenjun1 ; Viacheslav Galaktionov >> ; Su, Simei >> Cc: Denis Pryazhennikov ; >> dev@dpdk.org >> Subject: Re: CRC offload from application's POV >> >> On 10/12/2022 3:29 AM, Wu, Wenjun1 wrote: >>> >>> >>>> -----Original Message----- >>>> From: Ferruh Yigit >>>> Sent: Tuesday, October 11, 2022 9:46 PM >>>> To: Viacheslav Galaktionov ; >>>> Su, Simei ; Wu, Wenjun1 >>>> Cc: Denis Pryazhennikov ; >>>> dev@dpdk.org >>>> Subject: Re: CRC offload from application's POV >>>> >>>> On 10/11/2022 12:54 PM, Viacheslav Galaktionov wrote: >>>>> On 10/11/22 15:36, Ferruh Yigit wrote: >>>>>> On 10/11/2022 11:48 AM, Viacheslav Galaktionov wrote: >>>>>>> Hi! >>>>>>> >>>>>>> We're looking to implement CRC offload in our driver and we're >>>>>>> having difficulties understanding what the feature changes from >>>>>>> the application's point of view. If we enable the KEEP_CRC >>>>>>> offload, then the NIC is supposed to preserve the CRC in the >>>>>>> packet, that much is clear. But we checked other drivers and it >>>>>>> seems common for PMDs to remove the CRC from the final mbufs. >>>>>>> Why is that? >>>>>>> >>>>>>> We couldn't find any place where the CRC would be stored after >>>>>>> removal, so it looks like the application doesn't have access to >>>>>>> this piece of data. And if so, what's the point of having this >>>>>>> feature if the CRC is discarded either way? >>>>>>> >>>>>>> We're probably missing something and would really appreciate any >>>>>>> help with this. >>>>>>> >>>>>> >>>>>> Hi Viacheslav, >>>>>> >>>>>> As you said default behavior is to strip the CRC from packet, even >>>>>> some devices doesn't support having CRC in the packet it is removed >>>>>> by HW automatically. In this case application can't access to the CRC. >>>>>> >>>>>> For the devices that has capability to keep CRC, KEEP_CRC offload >>>>>> should enable having CRC as part of the packet. There is no special >>>>>> field to store the CRC. >>>>>> >>>>> I'm asking because I'm seeing a common pattern in the code base: if >>>>> the hardware didn't remove the CRC, the driver does this itself. >>>>> Grepping the code for "crc_len" will show you what I mean. One of >>>>> the most apparent examples of this happening can be seen in >>>>> drivers/net/e1000/em_rxtx.c: >>>>> >>>>> /* >>>>>  * This is the last buffer of the received packet. >>>>>  * If the CRC is not stripped by the hardware: >>>>>  *   - Subtract the CRC    length from the total packet length. >>>>>  *   - If the last buffer only contains the whole CRC or a part >>>>>  *     of it, free the mbuf associated to the last buffer. >>>>>  *     If part of the CRC is also contained in the previous >>>>>  *     mbuf, subtract the length of that CRC part from the >>>>>  *     data length of the previous mbuf. >>>>>  */ >>>>> >>>>> I don't understand why this is necessary, and whether this is just a >>>>> particularity of this driver or how the feature is supposed to be >>>>> implemented everywhere. I haven't checked every driver, but it seems >>>>> like a lot of them do something similar to this. >>>> >>>> That looks wrong to me too, cc'ed maintainers for comment. >>>> >>>> That piece of code seems remaining from first upstream of the driver >>>> (2012), it is before KEEP_CRC change, looks like it is missed. >>>> >>>> CRC should be kept in the packet if driver supports it and user >>>> requested KEEP_CRC offload. >>>> >>>> But Rx stats should not include CRC, as it is common to use 'm->pkt_len' >>>> for received packet stat, when CRC is in packet that should taken >>>> into account for stats. >>> >>> I agree with Ferruh. PMD will advertise KEEP_CRC offload in >>> rte_eth_dev_info->rx_offload_capa. If it is supported, CRC will always >>> keep in the packets. If user request KEEP_CRC offload in >>> rte_eth_rxmode, the driver will subtract CRC length from data length >>> to remove CRC from packet data, and user can get the CRC after the end of >> the packet. >>> >> >> Hi Wenjun, >> >> What we said is slightly different, it is OK to subtract the length from *stats*, >> but I think driver shouldn't remove the CRC from packet data. > You are right, the driver will never remove the CRC from packet data. Just to be sure we are on same page, driver won't remove the CRC only when KEEP_CRC is requested by user. Otherwise it will remove the CRC by default.