netdev - Re: [PATCH net-next v2 0/4] add HSR offloading support for DSA switches

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 for Android: free password hash cracker in your pocket

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

Date:   Sat, 13 Feb 2021 02:43:50 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Tobias Waldekranz <tobias@...dekranz.com>
Cc:     George McCollister <george.mccollister@...il.com>,
        Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Jonathan Corbet <corbet@....net>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v2 0/4] add HSR offloading support for DSA
 switches

On Sat, Feb 13, 2021 at 12:52:36AM +0100, Tobias Waldekranz wrote:
> On Wed, Feb 10, 2021 at 23:55, Vladimir Oltean <olteanv@...il.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.