From: Ido Schimmel <idosch@idosch.org>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: Nikolay Aleksandrov <nikolay@nvidia.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Roopa Prabhu <roopa@nvidia.com>, Ido Schimmel <idosch@nvidia.com>,
Jakub Kicinski <kuba@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
Vivien Didelot <vivien.didelot@gmail.com>,
Vladimir Oltean <olteanv@gmail.com>, Jiri Pirko <jiri@nvidia.com>
Subject: Re: [RFC PATCH net-next 00/15] Synchronous feedback on FDB add/del from switchdev to the bridge
Date: Wed, 27 Oct 2021 10:24:39 +0300 [thread overview]
Message-ID: <YXj+txwYHJVsI1sv@shredder> (raw)
In-Reply-To: <20211026215153.lpdk66rjvsodmxto@skbuf>
On Tue, Oct 26, 2021 at 09:51:54PM +0000, Vladimir Oltean wrote:
> I'll let Ido answer here. As I said, the model I'm working with is that
> of autonomous learning, so for me, no. Whereas the Spectrum model is
> that of secure learning. I expect that it'd be pretty useless to set up
> software assisted secure learning if you're just going to say yes and
> learn all addresses anyway. I've never seen Spectrum documentation, but
> I would be shocked if it wouldn't be able to be configured to operate in
> the bare-bones autonomous learning mode too.
Hi,
Yes, you are correct. It can support automatic learning, but it was
never enabled. We update the software bridge about learned FDB entries
(unlike DSA I think?), so secure learning makes sense in our case.
prev parent reply other threads:[~2021-10-27 7:24 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-25 22:24 [RFC PATCH net-next 00/15] Synchronous feedback on FDB add/del from switchdev to the bridge Vladimir Oltean
2021-10-25 22:24 ` [RFC PATCH net-next 01/15] net: bridge: remove fdb_notify forward declaration Vladimir Oltean
2021-10-25 22:24 ` [RFC PATCH net-next 02/15] net: bridge: remove fdb_insert " Vladimir Oltean
2021-10-25 22:24 ` [RFC PATCH net-next 03/15] net: bridge: rename fdb_insert to fdb_add_local Vladimir Oltean
2021-10-25 22:24 ` [RFC PATCH net-next 04/15] net: bridge: rename br_fdb_insert to br_fdb_add_local Vladimir Oltean
2021-10-25 22:24 ` [RFC PATCH net-next 05/15] net: bridge: move br_fdb_replay inside br_switchdev.c Vladimir Oltean
2021-10-25 22:24 ` [RFC PATCH net-next 06/15] net: bridge: create a common function for populating switchdev FDB entries Vladimir Oltean
2021-10-25 22:24 ` [RFC PATCH net-next 07/15] net: switchdev: keep the MAC address by value in struct switchdev_notifier_fdb_info Vladimir Oltean
2021-10-25 22:24 ` [RFC PATCH net-next 08/15] net: bridge: take the hash_lock inside fdb_add_entry Vladimir Oltean
2021-10-25 22:24 ` [RFC PATCH net-next 09/15] net: bridge: rename fdb_notify to br_fdb_notify Vladimir Oltean
2021-10-25 22:24 ` [RFC PATCH net-next 10/15] net: switchdev: merge switchdev_handle_fdb_{add,del}_to_device Vladimir Oltean
2021-10-25 22:24 ` [RFC PATCH net-next 11/15] net: bridge: make fdb_add_entry() wait for switchdev feedback Vladimir Oltean
2021-10-25 22:24 ` [RFC PATCH net-next 12/15] net: rtnetlink: pass extack to .ndo_fdb_del Vladimir Oltean
2021-10-25 22:24 ` [RFC PATCH net-next 13/15] net: bridge: wait for errors from switchdev when deleting FDB entries Vladimir Oltean
2021-10-25 22:24 ` [RFC PATCH net-next 14/15] net: dsa: propagate feedback to SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE Vladimir Oltean
2021-10-25 22:24 ` [RFC PATCH net-next 15/15] net: dsa: propagate extack to .port_fdb_{add,del} Vladimir Oltean
2021-10-26 10:40 ` [RFC PATCH net-next 00/15] Synchronous feedback on FDB add/del from switchdev to the bridge Nikolay Aleksandrov
2021-10-26 11:25 ` Vladimir Oltean
2021-10-26 12:20 ` Nikolay Aleksandrov
2021-10-26 12:38 ` Ido Schimmel
2021-10-26 16:54 ` Vladimir Oltean
2021-10-26 17:10 ` Nikolay Aleksandrov
2021-10-26 19:01 ` Vladimir Oltean
2021-10-26 19:56 ` Nikolay Aleksandrov
2021-10-26 21:51 ` Vladimir Oltean
2021-10-26 22:27 ` Nikolay Aleksandrov
2021-10-27 9:20 ` Nikolay Aleksandrov
2021-10-27 9:36 ` Nikolay Aleksandrov
2021-10-27 7:24 ` Ido Schimmel [this message]
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=YXj+txwYHJVsI1sv@shredder \
--to=idosch@idosch.org \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=idosch@nvidia.com \
--cc=jiri@nvidia.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nikolay@nvidia.com \
--cc=olteanv@gmail.com \
--cc=roopa@nvidia.com \
--cc=vivien.didelot@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).