On 2025/1/24 22:34, Morten Brørup wrote: >> From: Dengdui Huang [mailto:huangdeng...@huawei.com] >> Sent: Friday, 24 January 2025 11.00 >> >> 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. >> >> [1] https://inbox.dpdk.org/dev/20240206011030.2007689-1- >> haij...@huawei.com/ >> >> Signed-off-by: Dengdui Huang <huangdeng...@huawei.com> >> --- > > 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. > Currently, when the CRC data is stored at the end of a packet, neither data_len nor pkt_len contains the CRC length. Therefore, using rte_pktmbuf_copy() and linearization() for packets containing CRC data is also problematic.
> 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. > > It's a good idea to store it in mbuf dynfield. As mentioned above, storing CRC data at the end of the mbuf is very complex and currently imperfect. Can this feature be re-implemented in this simpler way?
