netdev - Re: [RFC PATCH 0/4] Faster ndo_fdb_dump for drivers with shared FDB

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: <187e4376-e7bb-3e12-f746-8cb3d11f0dc4@gmail.com>
Date:   Thu, 23 Sep 2021 15:29:07 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <vladimir.oltean@....com>,
        Roopa Prabhu <roopa@...dia.com>, Andrew Lunn <andrew@...n.ch>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH 0/4] Faster ndo_fdb_dump for drivers with shared FDB

On 9/23/21 8:25 AM, Vladimir Oltean wrote:
> Roopa, Andrew, Florian,
> 
> On Sun, Aug 22, 2021 at 12:00:14AM +0300, Vladimir Oltean wrote:
>> I have a board where it is painfully slow to run "bridge fdb". It has 16
>> switch ports which are accessed over an I2C controller -> I2C mux 1 ->
>> I2C mux 2 -> I2C-to-SPI bridge.
>>
>> It doesn't really help either that we traverse the hardware FDB of each
>> switch for every netdev, even though we already know all there is to
>> know the first time we traversed it. In fact, I hacked up some rtnetlink
>> and DSA changes, and with those, the time to run 'bridge fdb' on this
>> board decreases from 207 seconds to 26 seconds (2 FDB traversals instead
>> of 16), turning something intolerable into 'tolerable'.
>>
>> I don't know how much we care about .ndo_fdb_dump implemented directly
>> by drivers (and that's where I expect this to be most useful), because
>> of SWITCHDEV_FDB_ADD_TO_BRIDGE and all that. So this is RFC in case it
>> is helpful for somebody, at least during debugging.
>>
>> Vladimir Oltean (4):
>>   net: rtnetlink: create a netlink cb context struct for fdb dump
>>   net: rtnetlink: add a minimal state machine for dumping shared FDBs
>>   net: dsa: implement a shared FDB dump procedure
>>   net: dsa: sja1105: implement shared FDB dump
>>
>>  drivers/net/dsa/sja1105/sja1105_main.c        |  50 +++--
>>  .../ethernet/freescale/dpaa2/dpaa2-switch.c   |   9 +-
>>  drivers/net/ethernet/mscc/ocelot.c            |   5 +-
>>  drivers/net/ethernet/mscc/ocelot_net.c        |   4 +
>>  drivers/net/vxlan.c                           |   8 +-
>>  include/linux/rtnetlink.h                     |  25 +++
>>  include/net/dsa.h                             |  17 ++
>>  net/bridge/br_fdb.c                           |   6 +-
>>  net/core/rtnetlink.c                          | 105 +++++++---
>>  net/dsa/dsa2.c                                |   2 +
>>  net/dsa/dsa_priv.h                            |   1 +
>>  net/dsa/slave.c                               | 189 ++++++++++++++++--
>>  net/dsa/switch.c                              |   8 +
>>  13 files changed, 368 insertions(+), 61 deletions(-)
>>
>> -- 
>> 2.25.1
>>
> 
> Does something like this have any chance of being accepted?
> https://patchwork.kernel.org/project/netdevbpf/cover/20210821210018.1314952-1-vladimir.oltean@nxp.com/

Had not seen the link you just posted, in premise speeding up the FDB
dump sounds good to me, especially given that we typically have these
slow buses to work with.

These questions are probably super stupid and trivial and I really
missed reviewing properly your latest work, how do we manage to keep the
bridge's FDB and hardware FDB in sync given that switches don't
typically tell us when they learn new addresses?
--
Florian