Re: [PATCH dpdk v5] net/tap: use offsets provided by rte_net_get_ptype

[Stephen Hemminger <stephen@networkplumber.org>]

On Mon, 18 May 2026 10:27:00 +0200
Robin Jarry <rjarry@redhat.com> wrote:

> Instead of guessing what are the proper header lengths, pass
> a rte_net_hdr_lens struct to rte_net_get_ptype and use it to get the
> proper header lengths/offsets in tap_verify_csum.
> 
> This allows supporting stacked VLAN/QinQ tags and IPv6 extensions.
> 
> Signed-off-by: Robin Jarry <rjarry@redhat.com>

Still needs some polishing around Ipv6 ext headers
per AI review...

[PATCH dpdk v5] net/tap: use offsets provided by rte_net_get_ptype

The refactor is mechanically correct. rte_net_get_ptype() with a
non-NULL rte_net_hdr_lens fills l2_len walking the full VLAN/QinQ
stack (up to RTE_NET_VLAN_MAX_DEPTH), and for IPv4 sets
l3_len = rte_ipv4_hdr_len(ip4h). Replacing the local l2_len/l3_len
arithmetic with hlen->* preserves the existing bounds checks and
genuinely fixes the stacked-VLAN case (the old code only handled
single VLAN +4 or QinQ +8). The unnecessary cast of l4_hdr to
struct rte_udp_hdr * was correctly dropped. The {0} initializer on
the rte_net_hdr_lens stack variable is appropriate since
rte_net_get_ptype only writes the fields it parses.

Info:

  - The commit message says "This allows supporting stacked
    VLAN/QinQ tags and IPv6 extensions." The first half is true.
    The IPv6-extensions half is not: the else branch that catches
    RTE_PTYPE_L3_IPV6_EXT and returns is unchanged, and the
    accompanying comment "IPv6 extensions are not supported." in
    that branch is also unchanged. For an IPv6 packet with
    extension headers, rte_net_get_ptype() will set
    RTE_PTYPE_L3_IPV6_EXT (not RTE_PTYPE_L3_IPV6), so the
    else-if branch is skipped and tap_verify_csum() returns
    without verifying L3 or L4 checksums. The hlen now carries
    the correct l3_len including extensions, so this is a
    prerequisite for IPv6-ext support but not the feature itself.
    Suggest rewording to "This is a prerequisite for IPv6
    extension header support" or dropping that half of the
    sentence.

  - drivers/net/tap/rte_eth_tap.c:549: minor scoping observation
    only (no action needed) -- the hlen struct is filled
    unconditionally on every received packet whereas previously
    rte_net_get_ptype() was called with NULL when offload check
    was disabled. The cost is a handful of stack writes per
    packet; consistent with how other PMDs handle this.