From: sashiko-bot@kernel.org
To: wei.fang@oss.nxp.com
Cc: Frank.Li@kernel.org, imx@lists.linux.dev
Subject: Re: [PATCH v5 net-next 7/9] net: dsa: netc: add VLAN filter table and egress treatment management
Date: Fri, 12 Jun 2026 02:13:13 +0000 [thread overview]
Message-ID: <20260612021314.7C1001F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260611021458.2629145-8-wei.fang@oss.nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unconditional ETT/ECT allocation wastes hardware entries and may cause VLAN-unaware bridge traffic to egress with internal VLAN tags.
--
commit a87e1b42fde58831d28f51077ba31586a3d890f7
Author: Wei Fang <wei.fang@nxp.com>
net: dsa: netc: add VLAN filter table and egress treatment management
This commit implements the DSA .port_vlan_add and .port_vlan_del operations
to enable VLAN-aware bridge offloading on the NETC switch. It maintains
VLAN membership in the VLAN Filter Table and egress tagging through the
Egress Treatment Table.
> diff --git a/drivers/net/dsa/netc/netc_main.c b/drivers/net/dsa/netc/netc_main.c
> index d4475ad7ed6c2..9382e7b68e652 100644
> --- a/drivers/net/dsa/netc/netc_main.c
> +++ b/drivers/net/dsa/netc/netc_main.c
[ ... ]
> @@ -1025,6 +1054,385 @@ static void netc_switch_get_ip_revision(struct netc_switch *priv)
[ ... ]
> +static int netc_port_add_vlan_entry(struct netc_port *np, u16 vid,
> + bool untagged)
> +{
> + struct netc_switch *priv = np->switch_priv;
> + struct netc_vlan_entry *entry;
> + struct vft_cfge_data *cfge;
> + u32 index = np->dp->index;
> + u32 bitmap_stg;
> + int err;
> + u16 cfg;
[ ... ]
> + cfge = &entry->cfge;
> + cfge->et_eid = cpu_to_le32(NTMP_NULL_ENTRY_ID);
> + cfge->bitmap_stg = cpu_to_le32(bitmap_stg);
> + cfge->fid = cpu_to_le16(vid);
> + cfge->cfg = cpu_to_le16(cfg);
> + cfge->eta_port_bitmap = cpu_to_le32(priv->port_bitmap);
> +
> + if (untagged)
> + entry->untagged_port_bitmap = BIT(index);
> +
> + err = netc_add_vlan_egress_rule(priv, entry);
> + if (err)
> + goto free_vlan_entry;
[Severity: High]
Should this egress rule allocation be skipped for VLAN-unaware PVIDs?
In netc_port_vlan_egress_rule_changed(), there is a check noting that
VLAN-unaware VIDs have no egress rules. However, netc_port_add_vlan_entry()
unconditionally calls netc_add_vlan_egress_rule() for all VIDs.
When a port joins a VLAN-unaware bridge, netc_port_bridge_join() sets up
the internal PVID by calling netc_port_set_vlan_entry() with
untagged=false. Because ETT allocation is unconditional here, it appears
a limited Egress Treatment Table (ETT) and Egress Counter Table (ECT)
group is unnecessarily consumed for each VLAN-unaware bridge instance.
Since untagged=false is passed, does this incorrectly configure the ETT
entry to preserve the outer VLAN tag on egress (lacking the
FMTEID_VUDA_DEL_OTAG action)? This could result in hardware transmitting
untagged bridge traffic with the switch's internal PVID (e.g., 4095)
attached, potentially leaking internal configurations.
> +
> + err = ntmp_vft_add_entry(&priv->ntmp, vid, cfge);
> + if (err) {
> + dev_err(priv->dev,
> + "Failed to add VLAN %u entry on port %d\n",
> + vid, index);
> + goto delete_vlan_egress_rule;
> + }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611021458.2629145-1-wei.fang@oss.nxp.com?part=7
next prev parent reply other threads:[~2026-06-12 2:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-11 2:14 [PATCH v5 net-next 0/9] net: dsa: netc: add bridge mode support wei.fang
2026-06-11 2:14 ` [PATCH v5 net-next 1/9] net: enetc: add interfaces to manage dynamic FDB entries wei.fang
2026-06-11 2:14 ` [PATCH v5 net-next 2/9] net: enetc: add "Update" and "Delete" operations to VLAN filter table wei.fang
2026-06-11 2:14 ` [PATCH v5 net-next 3/9] net: enetc: add interfaces to manage egress treatment table wei.fang
2026-06-11 2:14 ` [PATCH v5 net-next 4/9] net: enetc: add "Update" operation to the egress count table wei.fang
2026-06-11 2:14 ` [PATCH v5 net-next 5/9] net: dsa: netc: initialize the group bitmap of ETT and ECT wei.fang
2026-06-12 2:13 ` sashiko-bot
2026-06-12 2:29 ` Wei Fang (OSS)
2026-06-11 2:14 ` [PATCH v5 net-next 6/9] net: enetc: add helpers to set/clear table bitmap wei.fang
2026-06-11 2:14 ` [PATCH v5 net-next 7/9] net: dsa: netc: add VLAN filter table and egress treatment management wei.fang
2026-06-12 2:13 ` sashiko-bot [this message]
2026-06-12 2:38 ` Wei Fang (OSS)
2026-06-11 2:14 ` [PATCH v5 net-next 8/9] net: dsa: netc: add bridge mode support wei.fang
2026-06-11 2:14 ` [PATCH v5 net-next 9/9] net: dsa: netc: implement dynamic FDB entry ageing wei.fang
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=20260612021314.7C1001F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=imx@lists.linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
--cc=wei.fang@oss.nxp.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.