I have also found some bugs about the tunnel packet type parsing API[1], including one of the problems fixed by this patch.
[1] https://patchwork.dpdk.org/project/dpdk/list/?series=35233 On 2025/5/21 13:11, sk...@marvell.com wrote: > From: Sunil Kumar Kori <sk...@marvell.com> > > While parsing packet headers, offset must be added to get next > header but for geneve header parsing offset is overwritten. > Also inner_l2_len is not set in case of geneve packets. > > Fixes: 64ed7f854cf4 ("net: add tunnel packet type parsing") > > Signed-off-by: Sunil Kumar Kori <sk...@marvell.com> > --- > lib/net/rte_net.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/lib/net/rte_net.c b/lib/net/rte_net.c > index be24690fdf..1264f33d61 100644 > --- a/lib/net/rte_net.c > +++ b/lib/net/rte_net.c > @@ -251,7 +251,8 @@ ptype_tunnel_with_udp(uint16_t *proto, const struct > rte_mbuf *m, > if (unlikely(gnh == NULL)) > return 0; > geneve_len = sizeof(*gnh) + gnh->opt_len * 4; > - *off = geneve_len; > + *off += geneve_len; > + hdr_lens->inner_l2_len = sizeof(struct rte_udp_hdr) + > geneve_len; The l2_len in mbuf is also calculated from the outer L4 header, so it is calculated in the same way here. However, this is easy to be misunderstood, can we add a note to inner_l2_len as follows? struct rte_net_hdr_lens { uint8_t l2_len; /* Outer_L4_len + ... + inner L2_len for tunneling pkt. */ uint8_t inner_l2_len; uint16_t l3_len; uint16_t inner_l3_len; uint16_t tunnel_len; uint8_t l4_len; uint8_t inner_l4_len; }; > *proto = gnh->proto; > if (gnh->proto == 0) > *proto = rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV4);
