netdev - DSA: some questions regarding TX forwarding offload

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 5 Oct 2021 08:54:34 +0000
From:   Alvin Šipraga <ALSI@...g-olufsen.dk>
To:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     Vladimir Oltean <vladimir.oltean@....com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>
Subject: DSA: some questions regarding TX forwarding offload

Hi,

I am trying to implement TX forwarding offload for my in-progress 
rtl8365mb DSA driver. I have some questions which I could use some 
clarification on. They might be specific to my hardware, which is also 
OK, but then some advice on how to proceed would be helpful.

Q1. Can the tagging driver somehow retrieve a port mask from the DSA 
switch driver in order to assemble the CPU->switch tag on xmit? Is there 
some infrastructure in place to share such data between the two drivers?

Q2. Is it expected by DSA that two isolated ports (e.g. two ports 
belonging to two separate bridges) can be members of the same VLAN 
without issue?

Background: The RTL8365MB's CPU tag includes an ALLOW field followed by 
a "port mask" field. If ALLOW=1 then - based on the VLAN tag in the 
frame and the port mask - the switch will automatically replicate the 
frame and egress it on all suitable ports, but only ports which are in 
the port mask.

If ALLOW=1, and if the port mask is all zeroes or all ones, then the 
switch will make its forwarding decision based only on the VLAN tag in 
the frame (if any). Now consider a configuration as follows:

         br0            br1
          +              +
          |              |
      +---+---+      +---+---+
      |       |      |       |
     swp0    swp1   swp2    swp3

... with both bridges containing switch port(s) belonging to the same 
VLAN n. How should I prevent - with TX forwarding offload - a packet 
with VID=n from being egressed on a port on the opposite bridge which 
belongs to the same VLAN n?

In the above scenario, either I must refine the CPU tag "port mask" 
(hence Q1), or I must restrict the hardware configuration in some way 
(hence Q2), or I must conclude that TX forwarding offload is not 
possible with these constraints, or there is some alternative solution 
or nuance that I have not thought of.

Thank you in advance,

	Alvin