netdev - Re: [RFC PATCH net-next 0/6] Rework DSA bridge TX forwarding offload API

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]

Message-ID: <87mtmkjgjp.fsf@waldekranz.com>
Date:   Thu, 04 Nov 2021 12:39:38 +0100
From:   Tobias Waldekranz <tobias@...dekranz.com>
To:     Vladimir Oltean <vladimir.oltean@....com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        DENG Qingfang <dqfext@...il.com>,
        Alvin ┼áipraga <alsi@...g-olufsen.dk>
Subject: Re: [RFC PATCH net-next 0/6] Rework DSA bridge TX forwarding
 offload API

On Tue, Nov 02, 2021 at 10:07, Vladimir Oltean <vladimir.oltean@....com> wrote:
> On Tue, Oct 26, 2021 at 07:26:19PM +0300, Vladimir Oltean wrote:
>> This change set replaces struct net_device *dp->bridge_dev with a
>> struct dsa_bridge *dp->bridge that contains some extra information about
>> that bridge, like a unique number kept by DSA.
>> 
>> Up until now we computed that number only with the bridge TX forwarding
>> offload feature, but it will be needed for other features too, like for
>> isolation of FDB entries belonging to different bridges. Hardware
>> implementations vary, but one common pattern seems to be the presence of
>> a FID field which can be associated with that bridge number kept by DSA.
>> The idea was outlined here:
>> https://patchwork.kernel.org/project/netdevbpf/patch/20210818120150.892647-16-vladimir.oltean@nxp.com/
>> (the difference being that with this new proposal, drivers would not
>> need to call dsa_bridge_num_find, instead the bridge_num would be part
>> of the struct dsa_bridge :: num passed as argument).
>> 
>> No functional change intended.
>
> Any feedback?

Sorry Vladimir, I've been on holiday. I will try to review this
ASAP. Based on a quick look, I like it.

I actually had some cross-chip fixes w.r.t. forward offloading queued
up, and this series should make that cleaner as well.