netdev - Re: [RFC net-next v3 09/10] net: bridge: mrp: Integrate MRP into the bridge

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <eac22f69-94ae-2a36-f974-9aa840ac9bfc@televic.com>
Date:   Tue, 28 Jan 2020 10:56:23 +0100
From:   Jürgen Lambrecht <j.lambrecht@...evic.com>
To:     Andrew Lunn <andrew@...n.ch>,
        "Allan W. Nielsen" <allan.nielsen@...rochip.com>
Cc:     Horatiu Vultur <horatiu.vultur@...rochip.com>,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        bridge@...ts.linux-foundation.org, jiri@...nulli.us,
        ivecera@...hat.com, davem@...emloft.net, roopa@...ulusnetworks.com,
        nikolay@...ulusnetworks.com, anirudh.venkataramanan@...el.com,
        olteanv@...il.com, jeffrey.t.kirsher@...el.com,
        UNGLinuxDriver@...rochip.com
Subject: Re: [RFC net-next v3 09/10] net: bridge: mrp: Integrate MRP into the
 bridge

On 1/27/20 2:40 PM, Andrew Lunn wrote:
>> Again, I do not know how other HW is designed, but all the SOC's we are
>> working with, does allow us to add a TCAM rule which can redirect these
>> frames to the CPU even on a blocked port.
> It is not in scope for what you are doing, but i wonder how we
> describe this in a generic Linux way? And then how we push it down to
> the hardware?
>
> For the Marvell Switches, it might be possible to do this without the
> TCAM. You can add forwarding DB entries marked as Management. It is
> unclear if this overrides the blocked state, but it would be a bit odd
> if it did not.
A MGMT frame does override the blocked state according the the datasheet.
And any MAC address can be loaded, not only 01:80:C2:00:00:0x (802.1D) and 01:80:C2:00:00:2x (GARP). Then the ATU is used instead of something specialized.
(referring to Andrew's email of 20200126 6:12 PM)
(I only checked again 88E6250/88E6220/88E6071/88E6070/88E6020 Functional Specification)


Kind regards,

Jürgen