From: Florian Fainelli <f.fainelli@gmail.com>
To: Vladimir Oltean <vladimir.oltean@nxp.com>,
Roopa Prabhu <roopa@nvidia.com>, Andrew Lunn <andrew@lunn.ch>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [RFC PATCH 0/4] Faster ndo_fdb_dump for drivers with shared FDB
Date: Thu, 23 Sep 2021 15:29:07 -0700 [thread overview]
Message-ID: <187e4376-e7bb-3e12-f746-8cb3d11f0dc4@gmail.com> (raw)
In-Reply-To: <20210923152510.uuelo5buk3yxqpjv@skbuf>
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
next prev parent reply other threads:[~2021-09-23 22:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-21 21:00 [RFC PATCH 0/4] Faster ndo_fdb_dump for drivers with shared FDB Vladimir Oltean
2021-08-21 21:00 ` [RFC PATCH 1/4] net: rtnetlink: create a netlink cb context struct for fdb dump Vladimir Oltean
2021-08-21 21:00 ` [RFC PATCH 2/4] net: rtnetlink: add a minimal state machine for dumping shared FDBs Vladimir Oltean
2021-08-21 21:00 ` [RFC PATCH 3/4] net: dsa: implement a shared FDB dump procedure Vladimir Oltean
2021-08-21 21:00 ` [RFC PATCH 4/4] net: dsa: sja1105: implement shared FDB dump Vladimir Oltean
2021-09-23 15:25 ` [RFC PATCH 0/4] Faster ndo_fdb_dump for drivers with shared FDB Vladimir Oltean
2021-09-23 22:29 ` Florian Fainelli [this message]
2021-09-23 22:49 ` Vladimir Oltean
2021-09-24 10:03 ` Nikolay Aleksandrov
2021-09-25 14:31 ` Roopa Prabhu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=187e4376-e7bb-3e12-f746-8cb3d11f0dc4@gmail.com \
--to=f.fainelli@gmail.com \
--cc=andrew@lunn.ch \
--cc=netdev@vger.kernel.org \
--cc=roopa@nvidia.com \
--cc=vladimir.oltean@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.