All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: William Bland <blandwwa@gmail.com>
Cc: Changchun Ouyang <changchun.ouyang@intel.com>,
	Huawei Xie <huawei.xhw@alibaba-inc.com>,
	dev@dpdk.org
Subject: Re: [PATCH 1/3] net: fix VLAN insert doc comment for shared-mbuf error code
Date: Mon, 24 Aug 2026 13:59:41 -0700	[thread overview]
Message-ID: <20260824135941.2c9bea11@phoenix.local> (raw)
In-Reply-To: <20260824192228.1197189-1-blandwwa@gmail.com>

On Mon, 24 Aug 2026 15:22:25 -0400
William Bland <blandwwa@gmail.com> wrote:

> The implementation returns -EINVAL when the mbuf is shared or
> indirect, but the doc comment inaccurately stated -EPERM.
> 
> Fixes: c974021a5949 ("ether: add soft vlan encap/decap")
> 
> Signed-off-by: William Bland <blandwwa@gmail.com>
> ---
>  lib/net/rte_ether.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/net/rte_ether.h b/lib/net/rte_ether.h
> index c9a0b536c3..cb10d8fb06 100644
> --- a/lib/net/rte_ether.h
> +++ b/lib/net/rte_ether.h
> @@ -387,7 +387,8 @@ static inline int rte_vlan_strip(struct rte_mbuf *m)
>   *   The packet mbuf.
>   * @return
>   *   - 0: On success
> - *   -EPERM: mbuf is shared overwriting would be unsafe
> + *   -EINVAL: overwriting would be unsafe because mbuf is shared or
> + *            indirect, or mbuf's first segment is too short
>   *   -ENOSPC: not enough headroom in mbuf
>   */
>  static inline int rte_vlan_insert(struct rte_mbuf **m)

This patch series is good and addresses bugs. But I would like it
to go a little further by:

1. Add cc: stable@dpdk.org to bugfixes
2. Do a little more refactoring so the new function can be marked experimental
3. Be more careful in the af_packet pkt_strip flag handling
4. Use test.h unit_test_suite_runner() pattern in existing test.

Long winded AI description of same stuff...

Review: [PATCH 0/3] VLAN insert with TPID / af_packet QinQ fix

Series applies cleanly on main (d55ccd4). All three Fixes: hashes
resolve. No correctness issues in the header change or the tests;
one pre-existing flag-handling problem in the af_packet Rx path is
touched by patch 3 and should be fixed separately (see below).

Patch 1/3: net: fix VLAN insert doc comment for shared-mbuf error code

Warning: Missing Cc: stable@dpdk.org. This is a fix (has a Fixes:
tag) for text that shipped in every stable branch.

Patch 2/3: net: add VLAN insert function with a TPID argument

Warning: rte_vlan_insert_tpid() is new public API and is not marked
__rte_experimental. The precedent in the same library is
rte_ipv4_cksum_simple() in rte_ip4.h, which carries the
"@warning @b EXPERIMENTAL" Doxygen note and the attribute.

Note the complication: as structured, the stable rte_vlan_insert()
wrapper calls rte_vlan_insert_tpid(). If the latter is marked
experimental, every translation unit that includes rte_ether.h
without ALLOW_EXPERIMENTAL_API gets the deprecated-attribute warning
from inside the wrapper body, which breaks existing users of the
stable function under -Werror. Suggested structure: move the body
into an unmarked helper and have both public functions call it.

	static inline int
	__rte_vlan_insert(struct rte_mbuf **m, uint16_t tpid)
	{
		/* current body */
	}

	static inline int rte_vlan_insert(struct rte_mbuf **m)
	{
		return __rte_vlan_insert(m, RTE_ETHER_TYPE_VLAN);
	}

	__rte_experimental
	static inline int
	rte_vlan_insert_tpid(struct rte_mbuf **m, uint16_t tpid)
	{
		return __rte_vlan_insert(m, tpid);
	}

Warning: No release notes entry. A new public function in lib/net
needs a line under "New Features" in
doc/guides/rel_notes/release_26_11.rst.

Warning: The unit tests for rte_vlan_insert() and
rte_vlan_insert_tpid() (app/test/test_net_ether.c, app/test/meson.build)
are added in patch 3, the af_packet fix. They test the library API
introduced here and should be part of this patch. That also keeps
the driver fix self-contained for backporting.

Patch 3/3: net/af_packet: fix QinQ outer TPID on VLAN reinsertion

Warning: The Rx VLAN block sets RTE_MBUF_F_RX_VLAN_STRIPPED
unconditionally and then, when vlan_strip is off, relies on
rte_vlan_insert_tpid() to clear it again. The non-strip path only
ends up with correct flags because the insert helper undoes the
flag; if the insert fails the mbuf is delivered with STRIPPED set
and an error logged. This dates from d41d39bcf7 ("net/af_packet:
reinsert stripped VLAN tag"), not from this patch, but this patch
reshapes exactly that block and is the place to sort it out. Split
it: one patch that fixes the flag handling (Fixes: d41d39bcf7,
Cc: stable), then the TPID change on top. Suggested shape for the
first:

	if (ppd->tp_status & TP_STATUS_VLAN_VALID) {
		mbuf->vlan_tci = ppd->tp_vlan_tci;
		mbuf->ol_flags |= RTE_MBUF_F_RX_VLAN;

		if (pkt_q->vlan_strip) {
			mbuf->ol_flags |= RTE_MBUF_F_RX_VLAN_STRIPPED;
		} else if (rte_vlan_insert(&mbuf) != 0) {
			PMD_LOG(ERR, "Failed to reinsert VLAN tag");
			mbuf->ol_flags |= RTE_MBUF_F_RX_VLAN_STRIPPED;
		}
	}

Warning: Missing Cc: stable@dpdk.org on a bug fix. Because the fix
depends on the new function from patch 2, a backport will need that
patch as well; worth stating in the commit message so the stable
maintainers know to pick both.

Warning: The tests add a second REGISTER_FAST_TEST
(vlan_insert_autotest) to test_net_ether.c alongside
net_ether_autotest. Use unit_test_suite_runner() instead: convert
the existing test_net_ether() into a suite with TEST_CASE entries
for the four address tests, add the two VLAN insert cases, and
create/free the mempool in the suite's .setup/.teardown so the
individual cases do not need a mempool parameter. That also
replaces the fprintf()/return -1 error reporting in
test_vlan_insert() with the TEST_ASSERT macros used elsewhere in
the file.

Info: test_vlan_insert_tpid() builds a frame that already carries an
802.1Q tag and then inserts an 802.1ad outer tag, but only checks
the new outer header. Checking that the pushed-down inner tag
survived (new vh->eth_proto == RTE_ETHER_TYPE_VLAN, and the following
rte_vlan_hdr still has TCI 200 / eth_proto IPv4) is what actually
exercises the QinQ case the test is named for.

Info: alloc_frame() comment says the header is "followed by
payload_len zero bytes" but rte_pktmbuf_append() does not zero the
data; either memset the payload or drop "zero" from the comment.

      parent reply	other threads:[~2026-08-24 20:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-24 19:22 [PATCH 1/3] net: fix VLAN insert doc comment for shared-mbuf error code William Bland
2026-08-24 19:22 ` [PATCH 2/3] net: add VLAN insert function with a TPID argument William Bland
2026-08-24 19:22 ` [PATCH 3/3] net/af_packet: fix QinQ outer TPID on VLAN reinsertion William Bland
2026-08-24 20:59 ` Stephen Hemminger [this message]

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=20260824135941.2c9bea11@phoenix.local \
    --to=stephen@networkplumber.org \
    --cc=blandwwa@gmail.com \
    --cc=changchun.ouyang@intel.com \
    --cc=dev@dpdk.org \
    --cc=huawei.xhw@alibaba-inc.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.