On Sat, Feb 13, 2021 at 12:52:36AM +0100, Tobias Waldekranz wrote: > On Wed, Feb 10, 2021 at 23:55, Vladimir Oltean <olte...@gmail.com> wrote: > > On Wed, Feb 10, 2021 at 10:10:14PM +0100, Tobias Waldekranz wrote: > >> This whole thing sounds an awful lot like an FDB. I suppose an option > >> would be to implement the RedBox/QuadBox roles in the bridge, perhaps by > >> building on the work done for MRP? Feel free to tell me I'm crazy :) > > > > As far as I understand, the VDAN needs to generate supervision frames on > > behalf of all nodes that it proxies. Therefore, implementing the > > RedBox/QuadBox in the bridge is probably not practical. What I was > > discussing with George though is that maybe we can make hsr a consumer > > of SWITCHDEV_FDB_ADD_TO_DEVICE events, similar to DSA with its > > assisted_learning_on_cpu_port functionality, and that would be how it > > populates its proxy node table. > > Is it not easier to just implement learning in the HSR layer? Seeing as > you need to look up the table for each packet anyway, you might as well > add a new entry on a miss. Otherwise you run the risk of filling up your > proxy table with entries that never egress the HSR device. Perhaps not > likely on this particular device, but on a 48-port switch with HSR > offloading it might be.
In the HSR layer, sure, I didn't mean to suggest otherwise, I thought you wanted to, when you said "I suppose an option would be to implement the RedBox/QuadBox roles in the bridge". So then the SWITCHDEV_FDB_ADD_TO_DEVICE events might be too much. Learning / populating the proxy node table can be probably done from the xmit function, with the only potential issue that the first packets will probably be lost, since no supervision frames have yet been transmitted for those proxied nodes. > This should also work for more exotic configs with multiple macvlans for > example: > > macvlan0 macvlan1 > \ / > hsr0 > / \ > swp1 swp2 Yes, I don't think macvlan uses switchdev. > > A RedBox becomes a bridge with one HSR > > interface and one or more standalone interfaces, and a QuadBox becomes a > > bridge with two HSR interfaces. How does that sound? > > Yeah that is the straight forward solution, and what I tried to describe > earlier in the thread with this illustration: > > >> >> br0 > >> >> / \ > >> >> hsr0 \ > >> >> / \ \ > >> >> swp1 swp2 swp3 > > I just wanted to double check that we had not overlooked a better > solution outside of the existing HSR code. I'm not aware of a better solution, but I'm also interested if there is one.
