Re: [PATCH] net/rte_net: fix inner L2 length for tunneled Ethernet packets

[Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>]

On 8/11/25 13:13, Khadem Ullah wrote:
> 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 <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:
> 
>   *
> 
>     apply matches to both outer and inner packet headers during entire
>     offload procedure;
> 
>   *
> 
>     restore outer header of partially offloaded packet;
> 
>   *
> 
>     model is implemented as a set of helper functions.
> 
> 
> 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)

I'm sorry, it is all very interesting, but I don't understand how it is
related to inner_l2_len definition discussion.

Also, please, stop top posting.


> On Mon, Aug 11, 2025 at 2:39 PM Andrew Rybchenko 
> <andrew.rybchenko@oktetlabs.ru <mailto: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
>     <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/ <https://dreambigsemi.com/>