Message-ID: <20211007113448.y4ijmlthgf4qxejz@skbuf>
Date:   Thu, 7 Oct 2021 11:34:48 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Alvin Šipraga <ALSI@...g-olufsen.dk>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>
Subject: Re: DSA: some questions regarding TX forwarding offload

On Thu, Oct 07, 2021 at 11:22:32AM +0000, Alvin Šipraga wrote:
> >> 	spa: source port address, i.e. the port that learned
> >> 	fid: FID (of the VLAN)
> >> 	efid: EFID (of the port)
> >>
> >> I also tried sending untagged frames from the network and cycling
> >> through one of the VLANs as PVID, in which case the port would learn and
> >> make an entry with vid_fid corresponding to the PVID.
> >>
> >> This suggests to me that the IVL field of the VLAN configuration really
> >> does achieve Independent VLAN learning, and that there are not many
> >> constraints here besides the size of the look-up-table.
> >
> > Can you repeat the experiment sweeping through EFIDs, but with the VLANs
> > configured for SVL and having the same FID? I would expect that the LUT
> > indices will be different, but still as many. Just want to confirm my
> > theory that the EFID provides port-based isolation regardless of IVL_EN.
>
> I was actually testing this just now.
>
> For VLANs with SVL same FID and EFID, the same MAC is learned into the
> same index, irrespective of VID (no surprise).
>
> However, cycling through the EFID, the same MAC is instead learned into
> 8 different indices.
>
> So yes, EFID provides port-based isolation regardless of IVL_EN. This is
> consistent with the description in the datasheet too.

Ok, so the EFID will be the basis for FDB isolation then. An EFID for
all standalone ports, and an EFID for each bridge.

> > Also, can you please repeat the IVL experiment but with VIDs not having
> > consecutive values, but rather N, N+16, N+32, N+48, ... N+2048 etc?
> > I would like to get to the bottom of that 4-bit FID thing.
>
> Sure. I ran the test as you suggested with N=100 and the results are the
> same: for 32 VLANs and cycling through the 8 EFIDs for each, I end up
> with 256 entries in the LUT. If I keep adding VLANs (note the limit is
> 32, but I can remove an old one and put a new one without losing the LUT
> entries of the old), then the LUT keeps just taking on entries.
>
> Considering this, do you agree with the mapping I suggested in the
> previous email?
>
> | SVL: {FID, EFID, MAC} -> index
> | IVL: {VID, EFID, MAC} -> index
>
> There doesn't seem to be any 4-bit resolution to the VID key when doing
> an IVL lookup.

If the 32 VLAN IDs are incremented in steps of 16, then yes, so it would
seem.

> > Yes, in case of hash collisions between unrelated entries on a full row,
> > returning -ENOSPC is clearly okay. This case is more interesting because
> > the LUT entries are not unrelated. I was commenting under the assumption
> > that you will need to give switchdev the impression that you are
> > offloading entries via IVL (so you should accept two FDB entries for the
> > same MAC DA in different VIDs, as long as they point towards the same
> > destination port) because that's how the hardware is going to treat them.
> > The only problematic case is when switchdev asks one FDB in one VLAN to
> > go one way, and another in another VLAN to go another way.
> >
> > [ by the way you can't propagate errors from .port_fdb_add to switchdev,
> >    and to the bridge, sorry ]
>
> OK, but I guess returning -ENOSPC in .port_fdb_add is the best a DSA
> driver can do, right?

Yeah, that part needs some work. It isn't simple stuff.

Powered by blists - more mailing lists