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 9567346128; Fri, 24 Jan 2025 15:35:40 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 50B5840E48; Fri, 24 Jan 2025 15:35:40 +0100 (CET) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 2886E402A3 for ; Fri, 24 Jan 2025 15:35:39 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id 055BE206CB; Fri, 24 Jan 2025 15:35:38 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [PATCH] mbuf: add packet offload Rx flag for keep CRC Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Jan 2025 15:34:24 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9F9E9@smartserver.smartshare.dk> X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <20250124095957.3496874-1-huangdengdui@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] mbuf: add packet offload Rx flag for keep CRC Thread-Index: AdtuRr5q8p4jA6OVQW6mTh1qf9pMJgAHOTVA References: <20250124095957.3496874-1-huangdengdui@huawei.com> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Dengdui Huang" , , Cc: , , , 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 > From: Dengdui Huang [mailto:huangdengdui@huawei.com] > Sent: Friday, 24 January 2025 11.00 >=20 > After discussion[1], the drivers do not include the CRC in the packet > length calculation. This will cause users to be confused about whether > the mbuf contains CRC data. This patch adds a packet offload Rx flag, > indicating that CRC data exists at the end of the mbuf chain. >=20 > [1] https://inbox.dpdk.org/dev/20240206011030.2007689-1- > haijie1@huawei.com/ >=20 > Signed-off-by: Dengdui Huang > --- Mbufs with F_RX_KEEP_CRC requires much more than this. If the packet length omits the 4 byte Ethernet CRC, and the last segment = only holds the CRC, rte_mbuf_check() will fail and cause panic in = rte_mbuf_sanity_check(). And many functions working on segments, such as rte_pktmbuf_copy(), = linearize(), etc. need to be patched to check for F_RX_KEEP_CRC when = working on the packet. This will degrade performance, and we are also = talking about frequently used dataplane functions. Furthermore, if we really need to support KEEP_CRC with segmented = packets, we need to add test cases with the CRC partially in the last = segment, and with only the CRC in the last segment, for functions and = libraries supporting segmented packets. Regardless if the packet length = includes the 4 bytes CRC or not. KEEP_CRC looks exotic to me, and am worried that full support for = KEEP_CRC will impact performance and would be essentially untested in a = bunch of libraries. I don't want exotic features impacting the = performance of frequently used dataplane functions. Can you please remind me of the use cases for KEEP_CRC? Perhaps support for KEEP_CRC could be a build time option (default = omitted, for performance and test coverage reasons)? Alternatively, support for KEEP_CRC could be limited to non-segmented = packets? Or, how about a completely different approach: Drivers supporting KEEP_CRC can strip the 4 byte CRC (like stripping a = VLAN tag) and store it in an mbuf dynfield.