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:   Thu, 23 Sep 2021 15:25:10 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Roopa Prabhu <roopa@...dia.com>, Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH 0/4] Faster ndo_fdb_dump for drivers with shared FDB

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ