From: Vladimir Oltean <olteanv@gmail.com>
To: Semih Baskan <strst.gs@gmail.com>
Cc: florian.fainelli@broadcom.com, jonas.gorski@gmail.com,
andrew@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, vladimir.oltean@nxp.com,
horms@kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net 1/2] net: dsa: let drivers offload 8021q uppers on standalone ports
Date: Mon, 10 Aug 2026 15:08:21 +0300 [thread overview]
Message-ID: <20260810120821.lykofvogbrn2y2ps@skbuf> (raw)
In-Reply-To: <CAAsRjR=RyiraYdLkOcHEagGKXK5+4zwQbT-Zq-1DwVkPiKUNpg@mail.gmail.com>
On Thu, Aug 06, 2026 at 04:39:00PM +0300, Semih Baskan wrote:
> Hi Vladimir,
>
> > But it doesn't, at least not in a sane way. If it still only accepts
> > those VLANs that have been added to filters by higher layers, it's not
> > VLAN-unaware. If a solution is not found to the problem, the driver must
> > reject operation as VLAN-unaware.
>
> You are right that the port is not VLAN-unaware. It cannot be: the VID
> lookup on this silicon cannot be turned off without the ARL loss from
> the other subthread. My mistake in the previous mail was arguing around
> that instead of saying it.
I understand from your discussion with Jonas that with the right IMP
port selection, you do get frames copied to the CPU even despite the
VLAN table miss. This is more in line with the expectations of higher
layers.
What about VLAN-unaware bridging? Can packets with VID=100 be forwarded
autonomously between two ports of a vlan_filtering=0 bridge if that VLAN
is not programmed to hardware? Does the behaviour depend on silicon
capabilities, or is it the same for all switches handled by the b53
driver?
next prev parent reply other threads:[~2026-08-10 12:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 7:31 [PATCH net 0/2] net: dsa: b53: fix 8021q uppers on standalone ports Semih Baskan
2026-08-06 7:31 ` [PATCH net 1/2] net: dsa: let drivers offload " Semih Baskan
2026-08-06 11:15 ` Vladimir Oltean
2026-08-06 11:44 ` Semih Baskan
2026-08-06 12:43 ` Vladimir Oltean
2026-08-06 13:39 ` Semih Baskan
2026-08-10 12:08 ` Vladimir Oltean [this message]
2026-08-06 7:31 ` [PATCH net 2/2] net: dsa: b53: " Semih Baskan
2026-08-06 8:39 ` [PATCH net 0/2] net: dsa: b53: fix " Jonas Gorski
2026-08-06 11:06 ` Semih Baskan
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=20260810120821.lykofvogbrn2y2ps@skbuf \
--to=olteanv@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=florian.fainelli@broadcom.com \
--cc=horms@kernel.org \
--cc=jonas.gorski@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=strst.gs@gmail.com \
--cc=vladimir.oltean@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox