From: "Arınç ÜNAL" <arinc.unal@arinc9.com>
To: "Jakub Kicinski" <kuba@kernel.org>,
"Florian Fainelli" <f.fainelli@gmail.com>,
"Vladimir Oltean" <olteanv@gmail.com>,
"Alvin Šipraga" <ALSI@bang-olufsen.dk>,
"Linus Walleij" <linus.walleij@linaro.org>,
"Andrew Lunn" <andrew@lunn.ch>,
"Luiz Angelo Daros de Luca" <luizluca@gmail.com>,
"DENG Qingfang" <dqfext@gmail.com>,
erkin.bozoglu@xeront.com
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Isolating DSA Slave Interfaces on a Bridge with Bridge Offloading
Date: Sun, 13 Mar 2022 14:23:47 +0300 [thread overview]
Message-ID: <7c046a25-1f84-5dc6-02ad-63cb70fbe0ec@arinc9.com> (raw)
Hi all,
The company I work with has got a product with a Mediatek MT7530 switch.
They want to offer isolation for the switch ports on a bridge. I have
run a test on a slightly modified 5.17-rc1 kernel. These commands below
should prevent communication between the two interfaces:
bridge link set dev sw0p4 isolated on
bridge link set dev sw0p3 isolated on
However, computers connected to each of these ports can still
communicate with each other. Bridge TX forwarding offload is implemented
on the MT7530 DSA driver.
What I understand is isolation works on the software and because of the
bridge offloading feature, the frames never reach the CPU where we can
block it.
Two solutions I can think of:
- Disable bridge offloading when isolation is enabled on a DSA slave
interface. Not the best solution but seems easy to implement.
- When isolation is enabled on a DSA slave interface, do not mirror the
related FDB entries to the switch hardware so we can keep the bridge
offloading feature for other ports.
I suppose this could only be achieved on switch specific DSA drivers so
the implementation would differ by each driver.
Cheers.
Arınç
next reply other threads:[~2022-03-13 11:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-13 11:23 Arınç ÜNAL [this message]
2022-03-13 13:32 ` Isolating DSA Slave Interfaces on a Bridge with Bridge Offloading Vladimir Oltean
2022-03-14 13:13 ` Arınç ÜNAL
2022-03-14 14:00 ` Vladimir Oltean
2022-04-10 13:00 ` Arınç ÜNAL
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=7c046a25-1f84-5dc6-02ad-63cb70fbe0ec@arinc9.com \
--to=arinc.unal@arinc9.com \
--cc=ALSI@bang-olufsen.dk \
--cc=andrew@lunn.ch \
--cc=dqfext@gmail.com \
--cc=erkin.bozoglu@xeront.com \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=luizluca@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.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