Hi, On Fri, 1 Aug 2025, Khadem Ullah wrote:
Hi Andrew, Thanks for your feedback. Please check mbuf packet types and the following test case: https://doc.dpdk.org/dts-20.02/test_plans/uni_pkt_test_plan.html#test-case-vxlan-tunnel-packet-type-detect sendp([Ether()/IP()/UDP()/Vxlan()/Ether()/IP(frag=5)/Raw('\0'*40)], iface=txItf) (outer) L2 type: ETHER (outer) L3 type: IPV4_EXT_UNKNOWN (outer) L4 type: Unknown Tunnel type: GRENAT Inner L2 type: ETHER Inner L3 type: IPV4_EXT_UNKNOWN Inner L4 type: L4_FRAG union { uint32_t packet_type; /**< L2/L3/L4 and tunnel information. */ __extension__ struct { uint8_t l2_type:4; /**< (Outer) L2 type. */ uint8_t l3_type:4; /**< (Outer) L3 type. */ uint8_t l4_type:4; /**< (Outer) L4 type. */ uint8_t tun_type:4; /**< Tunnel type. */ union { uint8_t inner_esp_next_proto; /**< ESP next protocol type, valid if * RTE_PTYPE_TUNNEL_ESP tunnel type is set * on both Tx and Rx. */ __extension__ struct { uint8_t inner_l2_type:4; /**< Inner L2 type. */ uint8_t inner_l3_type:4; /**< Inner L3 type. */ }; }; uint8_t inner_l4_type:4; /**< Inner L4 type. */ }; }; Based on the above, it seems that inner_l2_len have to the length of Ether. Ther might need to be some correspondent between both fields to potray the same information. Or, the inner_l2_type and inner_l2_len are completly different ?
On the one hand, there is mbuf structure, which has got no 'tunnel_len' field. It has 'l2_len' field [1] with a comment saying that for a tunnel packet, it includes some extra terms apart from just 'inner L2 header size'. This use of the 'l2_len' mbuf field is absolutely legitimate, and PMDs confirm this stance. On the other hand, there is 'rte_net_hdr_lens' structure [2], which does have a separate 'tunnel_len' field and, in general, has got slightly different naming. And the 'inner_l2_len' field has a comment that looks almost like a copy-paste from the mbuf structure. So does 'inner_l2_len' really need to include extra terms, given the presence of a dedicated 'tunnel_len' field? Is it at all correct or could it have been overlooked? One should take a closer look. [1] https://github.com/DPDK/dpdk/blob/b222395561638f89562e4ef42e1eabf2d6db43dd/lib/mbuf/rte_mbuf_core.h#L628 [2] https://github.com/DPDK/dpdk/blob/b222395561638f89562e4ef42e1eabf2d6db43dd/lib/net/rte_net.h#L22 Thank you.
Best Regards, Khadem
