Message-ID: <871r4xbv8x.fsf@waldekranz.com>
Date:   Thu, 07 Oct 2021 01:15:26 +0200
From:   Tobias Waldekranz <tobias@...dekranz.com>
To:     Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <vladimir.oltean@....com>,
        Alvin Šipraga <ALSI@...g-olufsen.dk>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Andrew Lunn <andrew@...n.ch>
Subject: Re: DSA: some questions regarding TX forwarding offload

On Tue, Oct 05, 2021 at 19:50, Florian Fainelli <f.fainelli@...il.com> wrote:
> On 10/5/2021 3:12 AM, Vladimir Oltean wrote:
>> I don't want to answer any of these questions until I understand how
>> does your hardware intend the FID and FID_EN bits from the DSA header to
>> be used. The FID only has 2 bits, so it is clear to me that it doesn't
>> have the same understanding of the term as mv88e6xxx, if the Realtek
>> switch has up to 4 FIDs while Marvell up to 4K.
>> 
>> You should ask yourself not only how to prevent leakage, but also the
>> flip side, how should I pass the packet to the switch in such a way that
>> it will learn its MAC SA in the right FID, assuming that you go with FDB
>> isolation first and figure that out. Once that question is answered, you
>> can in premise specify an allowance port mask which is larger than
>> needed (the entire mask of user ports) and the switch should only
>> forward it towards the ports belonging to the same FID, which are
>> roughly equivalent with the ports under a specific bridge. You can
>> create a mapping between a FID and dp->bridge_num. Makes sense or am I
>> completely off?
>> 
>
> Sorry for sort of hijacking this discussion.
>
> Broadcom switches do not have FIDs however using Alvin's topology, and 
> given the existing bridge support in b53, it also does not look like 
> there is leaking from one bridge to other because of the port matrix 
> configuration which is enforced in addition to the VLAN membership. 
> However based on what I see in tag_dsa.c for the transmit case with 
> skb->offload_fwd_mark, I would have to dig into the bridge's members in 
> order to construct a bitmask of ports to provide to tag_brcm.c, so that 
> does not really get me anywhere, does it?

Presumably this mask is generated in the driver somewhere whenever ports
joins/leaves bridges? Could you not just cache a copy of it in each
port's dp->priv? From there it is easy to get to it from the tagger on
xmit.

> Those switches also always do double VLAN tag (802.1ad) normalization 
> within their data path whenever VLAN is globally enabled within the 
> switch, so in premise you could achieve the same isolation by reserving 
> one of the outer VLAN tags per bridge, enabling IVL and hope that the 
> FDB is looked including the outer and inner VLAN tags and not just the 
> inner VLAN tag.
>
> If we don't have a FID concept, and not all switches do, how we can 
> still support tx forwarding offload here?

In principle, the deal you make with the bridge is basically:

   If you (bridge) give me (driver) a single skb, marked for offloading,
   to one of my ports, I promise to do the Right Thing™ and forward it
   to the same set of ports that you would have.

If your device needs a port mask instead of a fake DSA chip (what
mv88e6xxx does) in order to make that happen, that should be perfectly
fine.

So the FDB can either do lookups based on {DA} or {DA,VID}, but there is
no level of indirection there? I.e. you cannot have a set of VIDs map to
the same database?

In that case, my guess is that if you want to support multiple bridges
that operate completely independently wrt their FDBs, you will need to
allocate a VID per bridge like you say. That is the only field in the
lookup key that you can control. That VID could also be cached per-port
to keep the tagger overhead down.

> -- 
> Florian

Powered by blists - more mailing lists