netdev - Re: [RFC net-next Patch 0/3] net: bridge: mrp: Add support for Media Redundancy Protocol(MRP)

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]

Date:   Fri, 10 Jan 2020 22:03:37 +0200
From:   nikolay@...ulusnetworks.com
To:     David Miller <davem@...emloft.net>
CC:     horatiu.vultur@...rochip.com, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org, bridge@...ts.linux-foundation.org,
        roopa@...ulusnetworks.com, jakub.kicinski@...ronome.com,
        vivien.didelot@...il.com, andrew@...n.ch,
        jeffrey.t.kirsher@...el.com, olteanv@...il.com,
        anirudh.venkataramanan@...el.com, dsahern@...il.com,
        jiri@...lanox.com, UNGLinuxDriver@...rochip.com
Subject: Re: [RFC net-next Patch 0/3] net: bridge: mrp: Add support for Media Redundancy Protocol(MRP)

On 10 January 2020 21:27:36 EET, David Miller <davem@...emloft.net> wrote:
>From: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
>Date: Fri, 10 Jan 2020 16:13:36 +0200
>
>> I agree with Stephen here, IMO you have to take note of how STP has
>progressed
>> and that bringing it in the kernel was a mistake, these days mstpd
>has an active
>> community and much better support which is being extended. This looks
>best implemented
>> in user-space in my opinion with minimal kernel changes to support
>it. You could simply
>> open a packet socket with a filter and work through that, you don't
>need new netlink
>> sockets. I'm not familiar with the protocol so can't really be the
>judge of that, if
>> you present a good argument for needing a new netlink socket for
>these packets - then
>> sure, ok.
>
>With a userland implementation, what approach do you suggest for
>DSA/switchdev offload
>of this stuff?

Good question, there was no mention of that initially, or I missed it at least. 
There aren't many details about what/how will be offloaded right now.
We need more information about what will be offloaded and how it will fit. 



l