On Wed, 14 Oct 2026 11:13:58 +0530 Prashant Gupta <[email protected]> wrote:
> From: Hemant Agrawal <[email protected]> > > Extend dpaa2_dev_rx_parse_new() (LX2160A FRC fast path) to > identify IPv4/IPv6 fragmented packets, IPsec ESP, and > GTP-U/GTP-C packets. > > Map the corresponding parser summary values to DPDK packet > types. GTP-U and GTP-C packets are additionally marked with > RTE_PTYPE_L4_UDP to reflect the UDP transport used by the > outer tunnel header. > > Advertise the newly supported packet types through > dpaa2_supported_ptypes_get(). > > Signed-off-by: Hemant Agrawal <[email protected]> AI saw this is it an issue? [PATCH 09/11] net/dpaa2: parse tunnel and fragmented packet types Warning: the fragment value changed. v9 built it from DPAA2_PSR_SUMMARY_IP_FRAG, which is 1. v10 open-codes it as 2: #define DPAA2_PKT_TYPE_IPV4_FRAG \ (0x0002 | DPAA2_PKT_TYPE_IPV4) Code 1 is already DPAA2_PKT_TYPE_IPV4_EXT, so this looks like it was picked to avoid a duplicate case label rather than taken from the parser spec. If the hardware reports fragments as 1, the new FRAG cases never match and fragments keep coming up as RTE_PTYPE_L3_IPV4_EXT. Please confirm the summary code. If it is 1, drop the FRAG defines and report L4_FRAG from the existing EXT case: case DPAA2_PKT_TYPE_IPV4_EXT: m->packet_type = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT | RTE_PTYPE_L4_FRAG; break; Info: ESP and GTP values are now bare numbers (0x0005, 0x0014, 0x0015). Name them, as v9 did, so the next reader can check them against the parser summary table.
