On Thu, Dec 05, 2024 at 08:34:03PM +0200, Vladimir Oltean wrote: > On Thu, Dec 05, 2024 at 06:26:01PM +0100, Christian Marangi wrote: > > Concept looks handy, ideally I can just assign one ID for each port > > like: > > port 1 -> FIB 1 > > port 2 -> FIB 1 > > port 3 -> FIB 2 > > > > Question: > > Ports of the same bridge should have the same FIB? > > The answer, as well as many other explanations, is under the "Address > databases" section of Documentation/networking/dsa/dsa.rst. Please read > it through before starting to implement anything. > Ok sorry, will read. > > What I need to check is how the switch handle this for learning. Does > > the switch correctly create FDB entry with the right FIB? > > You're asking me how an8855 behaves? I have no idea, I never interacted > with it :-| > Noo it wasn't a question for you, it was really to describe a problem that might be present if the switch doesn't account for that and that I need to check. > The idea as far as the DSA API is concerned would be to learn addresses > in the bridge database (DSA_DB_BRIDGE) that the user port is configured > for, and not learn any addresses in the port-private database (DSA_DB_PORT). > > > If that's not the case then I think assisted_learning is needed and HW > > Learn can't be used? > > ds->assisted_learning_on_cpu_port applies, as suggested by its name, > only on the CPU port. On user ports, address learning should work normally. > > As you will find in the documentation, the CPU port is not like a user > port, in the sense that it is not configured to service a single address > database, but all of them. So, source learning on the CPU port will not > work unless the switch knows which address database should each packet > be associated with. Ok so in such case, learning on CPU needs to be disabled and assisted learning enabled. > > In principle, one way could be to pass, during tagger xmit, the database ID, > so that the switch knows that it must learn the MAC SA of this packet in > this FID. I don't have the full image of the Mediatek DSA tag format, > but if an8855 is anything like mt7530, this option isn't available. > Thus, like mt7530, it needs to set ds->assisted_learning_on_cpu_port, so > that software will call port_fdb_add() on the CPU port with the correct > dsa_db (for the right bridge) as argument. But I don't think that is > going to pose any sort of issue. > In theory I might have found just this option. Tagger documentation is totally missing but there are some c and header API that define some interesting option of the tagger. It seems the tagger can work in 3 way: - portmap (what we currently use) - portid - lookup result Now the last 2 mode seems very interesting. The naming is very confusing but maybe with portid they refer to the FIB. I need to check this. If that's the case then it's exactly what we need. They set an int so it's definetly an ID. I assume lookup result is to only use FDB to decide where the packet should go. In this mode no ID or port are defined. So in short lots of tests to do, maybe this can be handled in the tagger. > > (I still need to check if I can assign a default FIB for a port... > > Currently the STP register are 2 bit for each FIB id, so 16 different > > FIB are possible) > > > > Also do we have a script for selft tests? I remember there was one back > > in the days for fdb isolation? > > I don't remember right now, I don't think we do. I'll try to come up > with something in the following days. Yes that would be handy. -- Ansuel
