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] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 13 Feb 2021 00:52:36 +0100
From:   Tobias Waldekranz <tobias@...dekranz.com>
To:     Vladimir Oltean <olteanv@...il.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 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:
>> On Tue, Feb 09, 2021 at 11:04, George McCollister <george.mccollister@...il.com> wrote:
>> >> > It also doesn't implement a ProxyNodeTable (though that actually
>> >> > wouldn't matter if you were offloading to the xrs700x I think). Try
>> >> > commenting out the ether_addr_copy() line in hsr_xmit and see if it
>> >> > makes your use case work.
>> >>
>> >> So what is missing is basically to expand the current facility for
>> >> generating sequence numbers to maintain a table of such associations,
>> >> keyed by the SA?
>> >
>> > For the software implementation it would also need to use the
>> > ProxyNodeTable to prevent forwarding matching frames on the ring and
>> > delivering them to the hsr master port. It's also supposed to drop
>> > frames coming in on a redundant port if the source address is in the
>> > ProxyNodeTable.
>> 
>> 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.

This should also work for more exotic configs with multiple macvlans for
example:

macvlan0 macvlan1
      \  /
      hsr0
      /  \
   swp1  swp2

> 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.