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 E7289A0547; Wed, 12 Oct 2022 10:07:04 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DA2A042ECF; Wed, 12 Oct 2022 10:07:04 +0200 (CEST) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2078.outbound.protection.outlook.com [40.107.223.78]) by mails.dpdk.org (Postfix) with ESMTP id 8792542DC9 for ; Wed, 12 Oct 2022 10:07:02 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bz4mYnDhE9VGpbQhcTQqmwFEK3i1DEjr71yQjNVFFL1c8YLaYWAyX8ZmdLl0B0j9156lGi3O9H+UM9faZt6iPKQJ2Pta8CSh5qLcAC104UD1AcjPMiddhgpLR0ptZ5fLCxKUAByfrJkPjd0VQynJ76LuGA8ZSjo7mfHRCtk5eTrPxmASgM3/Q1Y/DNOBEXH3Yk9avkyjZjCBx1DY23Mun0T0w9/DSXshaMNtOU00YqmrA0tN9xtCpRhyywCP37IQXHH1buTw+8CMa/8IUwWJ79WvbzlsmahSFRoVg8MBboOjfNhW65+FvYQMaN1SH/DEZjpQxhSl+Uhbk1KZAeNwvg== 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=kWGw27nwPGGOgNy5vb7BMgJ05A7lVt+OD6D3iuo1Krw=; b=a++RVuFZviNgnK6mjY6E2VDfIGZOCltvGUijuOQuvCWhoOulbA1Zm8kNUEEwJ3oLenDULmNByEYd/rqgNsK70ejzBqzlPydwzfsFyvHXnLt7BpTvxvpPR6tqOp4rHEgrV33EcmfBj9ueJSgw4h0RbDKVz4xiLl+IdAx0OW3JUKwEnnrd1Pel+ej0DNGuM4OkBgT0HZ11Z78jgKmyh9O8uF2aijmphl7NyKi5NFVgf2SYmLAI/JC0G2YpAszO3f6pZIAQQE48cCfj0ddazOQ4CqA4Xj2l6WpLzpJuI0cIJ3rZ3f2VLItu5vWKWvJLSzv6s4U3FheYNPwl2AAy/6TuEg== 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=kWGw27nwPGGOgNy5vb7BMgJ05A7lVt+OD6D3iuo1Krw=; b=xEzjtmKzxzkbMAvzYcfFmzfnvIKuFv0Pch9NPQg9LPcFYHddmBCJF0Oh7K9/40iqZURrIHJ7DYb1gxV3c0VyBdFuTL9ftYB9cLBrO/O26QHXcp8QX3vy30mLqnln5TePt01Juket+hcq/0zN/I/cai+khuqxeZaayhjbKQrkIG8= 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 SJ1PR12MB6337.namprd12.prod.outlook.com (2603:10b6:a03:456::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5709.22; Wed, 12 Oct 2022 08:07:00 +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:06:59 +0000 Message-ID: <5e9224e3-7d38-9699-fc69-83d4dd9ab3ae@amd.com> Date: Wed, 12 Oct 2022 09:06:55 +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> From: Ferruh Yigit In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0215.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a5::22) To DM6PR12MB4297.namprd12.prod.outlook.com (2603:10b6:5:211::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM6PR12MB4297:EE_|SJ1PR12MB6337:EE_ X-MS-Office365-Filtering-Correlation-Id: ac073875-f12e-4983-995e-08daac28bd0a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: FwlJJzUN8RI76LI33rUfNhL09drOrBBllv7s43qQYmDX4smJWZkCVH0LaBMEclmDhYVg+lSfTjPW3KaGqjhX4IYJulvBDqGkm4ZA8MrABoiMPMYGj/t3wnYSxlh8fRqAWkqUZRAOL3zZD6IZ8RHx/6zPi8jZJXDdHnz1seZzuUQEL5sDXciN73cWePkSM8Gvv0kHBoHqwBjt+Vz0bfNBZvOiXGExUFcxEE+gsr1RdPo6kOCnSRBsf/Fzk6J2U886PNkCrKt+zr6AvUMTVo+TZ6jqNcPKw4hBznWWLyF4UGWIlzdz39oJSaWgFepd8MZ6Ltm0wBFkX2GHFQYgS0qsBg31zWIVqBpvUwc7gs/L+8y4uZOliTM334mz+swj6P9QCQ8qlqbPYqH4+FnBF56A6nai/KOfkvKE/qBPTvf+ytI99NPSruCvUwGTgN9kPAp8slyuHxmqCcXeovxfud8nfHIMOFQBBivaeSNqU+tgHiPhio4Z2sKD85WlAHGPDl+LIHAGFbZdCmI96dRHQgh1oNFwOEqbNyXldAzWXR9TEGDvhz/SlCIBJVjkylzW5KdQHwzmhXP4W+cihsWeMHVwFwsadFDCJwbDQ361tqdtMlkwRa5Pm/01GCPaY+XiIg1KMRtV8InVyJ4G3tH5tMK5woRghcoTpw9rKW5Yu1AvDLAmCzo7M56HprBdcpmTXdXg6BM+TR5qWiN5PFgwrdQlnTrH+nUMsBiqtzZt4YyhfZMcav0u58ykYUBXWwkitMKsqpw8pzDaLPbKW1UbFT8mPxV/UC9jSBaxhX1x/Vh4baM= 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)(136003)(39860400002)(396003)(346002)(366004)(376002)(451199015)(83380400001)(8676002)(86362001)(31696002)(38100700002)(2906002)(66946007)(41300700001)(44832011)(66556008)(66476007)(8936002)(5660300002)(2616005)(6512007)(26005)(4326008)(316002)(54906003)(110136005)(186003)(478600001)(6486002)(53546011)(6666004)(6506007)(31686004)(36756003)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QmsyRmJBaVdnNW9XTXlzNVpiMU9Wemhkd2xjOU50bmZLeWV3Tjl1ZTY2V1d4?= =?utf-8?B?UVcrU2hZZXBwQUJVSnFkVWxUNW5SUmtscm53RGpWYnVvVWgxWjMyVmdJRnFk?= =?utf-8?B?ZjJ1NGhNQ1V4c2E2NFJyVVhZWW1kU2pDb01BNnBLNHRuRG9mTzdGRzhxTlA1?= =?utf-8?B?QVlMUEppZXE1cFdsOEg0SmxNWFlXRGE3aENhZnFqTTVvNG1Ycm5Ca3dxZnZL?= =?utf-8?B?WllHQmMxTzJIa2dPWEJFOVQzdSt6K0pkNlphcFdJaGRLWEZTaC9LV2xXVXNs?= =?utf-8?B?bUJFMGtHaWpYc0gvQS9MSkxxd2FwdXREbzZvdDZYSitqUnNtMVFUSmZsb0ZK?= =?utf-8?B?UDd4Z1ZaWkdiOFVaVHRNWWpEUlU3NkkrZTlZUEs5SlJTUVI5L0dUbmhyUU5B?= =?utf-8?B?NVZrRkpLRVByMGUrNk1lMlh2c0xsazk2TENwNkl2T0N1WldiYzMydDl4L213?= =?utf-8?B?TnZkSVZ1cWE5enlFOWhTUXU2ZWRFSnRVTXpLaGMrU1NXV2FwdnN2SUZmbDFh?= =?utf-8?B?QXg4cVhobXMzRHdQb2R1eGE4eUpibjVsUTRBNFlRdW1TaHdqL1NMT1MvU3Ra?= =?utf-8?B?bU1vdkZoUU9CMFQ2NklBMTM3SVhFQjJuMzlWOUhKV29WRkIyYW9kM0dGQUtG?= =?utf-8?B?b1pvQXhTMVNKUDAyemFtdXgxWm1lY0pYRmdyWHBaNDFQcUs0cHByVVBNZnZp?= =?utf-8?B?Tk1CYWkwUWpHSk13dnpiWGMzVjZCZnpaTml5OWI5MWNmTXhEK0N5bHpRdTNN?= =?utf-8?B?Y3RqMzhjSFo4ZUVCbkY2VWFqbEl0T1B4dmh3VE5yeGhabWNIV0NHTzQ3Z2Nj?= =?utf-8?B?TzZCN21CME5xb1lSN0haMWUrUlB1cEl4NnV6eXJMTDFBYTN5QzdQRzhuTlFh?= =?utf-8?B?Q0tpdEhTQ2lSVlpoSS9QQzNSQ3VwMUVUZEpZWUNmc1lReWRuSEcrcjNEV2ha?= =?utf-8?B?eDFTdk8wTkJ4cGNRWE0zSWdXOTdGaXZqUjR2OFFQR3ZmTmlsL0daaVR6Z3k5?= =?utf-8?B?R005RlAwTW56dU5hb3hzZktlUEE3VHEreG84cDd6ZTFBT2JDYnNIUmZGY1Vi?= =?utf-8?B?Zkw1NVRnKzY5eUtUSzV6RGtDdVJ0Q1dpQXhXR21QeTB5bTVCWDcrZzNnbjln?= =?utf-8?B?NzlMYUlXRkQrbHRjQzVRRnRxR05NUlo2VFhyNXp6YzNwWk5nY0tNQVBDVXFD?= =?utf-8?B?c3duL0xEWEtkcVZDVENYaUZic3Njc2pWYkJ5dVh2MC96QTlKbnRrTVMxTkNG?= =?utf-8?B?WDdMQXVpWnY5clRSOG00R1pBMzlFMjEwTnkreXBtYWRsR1NLdjQxenBqRHNp?= =?utf-8?B?OElYUmlsUGJ2UW9IYUZMeGlHcWlaZTNIOU9YWnpYZjgvYkVBcFVVczB4cmc2?= =?utf-8?B?SzR5VFNvc25NakFoMHlBUE1FUHB2SlNrVFM1WHdZMUM4dDN6S1YxV1M1VEVN?= =?utf-8?B?SlhnM1J3VGVVRGhTdElyZlZVdFA4bmQ1ZTM5L1ZwZ1RWU3dtS1FqTVBhZklr?= =?utf-8?B?ckIwNnJOR2drNEgrSTg2MW9XeGhORlNrdmFhb1RnUkNJOWZVTDVQQWh3ckp3?= =?utf-8?B?NWZUaGc5V2FRNUlYQmdKQWZ6T2pJdXlxaTBuVVJWWHlVcWpKTmVqZDNBbnpv?= =?utf-8?B?akIwYUpqL01ZUGQxQWloTlpxcDlFeVJBSUxnamUwTE0zTVZaOVpWd045M2lu?= =?utf-8?B?ejhqS1Irdi90aHE3VnVxcVUyWEdJcys2MEhhUjJUMVRFdzhkcDVUaHBadFg0?= =?utf-8?B?cDlGWUx0bER3QVViWFVVcmdValdXQlI1dWZJV0szeE54cWpacDV4eUtGcEw5?= =?utf-8?B?MXVYOUpEYWhzNGRKQTB5Z1hEdituaE5yMS94NnlPR0FFUjhHMVA1QldoeTBR?= =?utf-8?B?MVAxOGVFTnpTZEtPeWZuOVFpUXNBK3hBMmdxUDVGTE81Ti85dHFNODU5cC94?= =?utf-8?B?ajR1cStNTmZpMWpFZmxKQzFKbFk0bFJiemI1elhSVGJ0QUkxL0Z2NHN4enpK?= =?utf-8?B?Q1RXWStJK28rUVhZVDNzUEtGZEh4TS9zZjBicGZMZWVLNjVoaUNVWTRyYngw?= =?utf-8?B?N2pqVWhJanlsUmcwR0RvdVp2TkJwajN1Lzh1WGMyc0MyMnVqaHZBYjlGbHp4?= =?utf-8?Q?BT5J4DIaGRCBPtkQqkvGjjo6d?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: ac073875-f12e-4983-995e-08daac28bd0a 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:06:59.8478 (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: w8cRN+tCUlYuc3hq1XhDNhKwCfrezqmpA4ZrY0L0WeBCgYWf+A5NRLydU4WVcKwK X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR12MB6337 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 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.