patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Khadem Ullah <14pwcse1224@uetpeshawar.edu.pk>
To: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Cc: dev@dpdk.org, jasvinder.singh@intel.com,
	bruce.richardson@intel.com,  thomas@monjalon.net,
	ivan.malov@arknetworks.am, stable@dpdk.org
Subject: Re: [PATCH] net/rte_net: fix inner L2 length for tunneled Ethernet packets
Date: Mon, 11 Aug 2025 15:13:46 +0500	[thread overview]
Message-ID: <CA++2-x71R+MGC0_ZmC3p8jJ4=q3ZaW3zQeNwrGMp2UuXTkQm0Q@mail.gmail.com> (raw)
In-Reply-To: <7416c5c9-7485-4de1-8006-78a6df128080@oktetlabs.ru>


[-- Attachment #1.1: Type: text/plain, Size: 4492 bytes --]

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:

   -

   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: 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/

[-- Attachment #1.2: Type: text/html, Size: 19379 bytes --]

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 69611 bytes --]

  reply	other threads:[~2025-08-11 10:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-28 13:12 Khadem Ullah
2025-07-28 13:28 ` Ivan Malov
2025-07-29  5:06   ` Khadem Ullah
2025-07-31 10:26     ` Andrew Rybchenko
2025-08-01 11:28       ` Khadem Ullah
2025-08-01 13:23         ` Ivan Malov
2025-08-11  9:39         ` Andrew Rybchenko
2025-08-11 10:13           ` Khadem Ullah [this message]
2025-08-11 11:22             ` Andrew Rybchenko
2025-08-11 12:17               ` Khadem Ullah
2025-07-31 10:21 ` Andrew Rybchenko
  -- strict thread matches above, loose matches on Subject: below --
2025-07-28 12:30 Khadem Ullah
2025-07-28 12:21 Khadem Ullah

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA++2-x71R+MGC0_ZmC3p8jJ4=q3ZaW3zQeNwrGMp2UuXTkQm0Q@mail.gmail.com' \
    --to=14pwcse1224@uetpeshawar.edu.pk \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=ivan.malov@arknetworks.am \
    --cc=jasvinder.singh@intel.com \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).