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.
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()
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 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