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.rybche...@oktetlabs.ru <mailto:andrew.rybche...@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/>
