public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
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ç

             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