Hi Andrew, 
You are right, but I haven't found any other reference to the specific usage of the definition i.e. in correspondence with vxlan_decap, 
tunneled offload API and in mbuf packet type . 
According to tunnel offload API, vxlan encap/decap action, the inner header represents the original header 
while the outer represents the encapsulated ones. 
if performed vxlan_decap, it will decapped the outermost and the inner header will remain the original header. 

Please also check tunnel offload api in https://doc.dpdk.org/guides-20.11/prog_guide/rte_flow.html

Tunnel Offload API provides hardware independent, unified model to offload tunneled traffic. Key model elements are:


E.g., the following two rules (tunnel offload) with  tunnel match and give the innermost packet. 
flow create 0 ingress group 0 tunnel_set 1 pattern eth / ipv4 / udp dst is 4789 / vxlan / end actions jump group 1 / end flow create 0 ingress group 1 tunnel_match 1 pattern eth / ipv4 / udp dst is 4789 / vxlan / eth / ipv4 / end actions queue index 3 / end

 
pkt = Ether(dst='24:aa:aa:aa:aa:11',src='50:bb:bb:bb:bb:22')/IP()/UDP(dport=4789,sport=4789)/VXLAN(vni=10)/
Ether(dst='24:cc:cc:cc:cc:33',src='50:dd:dd:dd:dd:44')/IP()/ UDP()

image.png
The outer headers were decapsulated and the inner header was redirected to queue 3. 

Incase of two tunneled packets, the outermost tunnel is stripped and the packet from the inner tunnel onward is forwarded to queue 3.

You can also check  (Action: VXLAN_DECAP) that performs a decapsulation action by stripping  

all headers of the VXLAN tunnel network overlay from the matched flow.

So, according to vxlan_decap and tunnel offload api, the inner header information must be the information of the innermost not the outmost. 

and then the following would be correct in testpmd: 
 92-bytes VXLAN packet size= (14-byte outer Ethernet header + 20-byte outer IP header + 8-byte outer UDP header + 8-byte VXLAN header )+

 (14-byte inner Ethernet header + 20-byte inner IP header  + 8-byte inner UDP)





On Mon, Aug 11, 2025 at 2:39 PM Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru> wrote:
On 8/1/25 14:28, 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.


Why?

> 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 ?

Definition says that it is different.

>
> Best Regards,
> Khadem



--
Engr. Khadem Ullah,
Software Engineer,
Dreambig Semiconductor Inc
https://dreambigsemi.com/