All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@nvidia.com>
To: Jonas Gorski <jonas.gorski@bisdn.de>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>,
	Roopa Prabhu <roopa@nvidia.com>,
	Nikolay Aleksandrov <razor@blackwall.org>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Simon Horman <horms@kernel.org>,
	Hans Schultz <schultz.hans@gmail.com>,
	"Hans J. Schultz" <netdev@kapio-technology.com>,
	bridge@lists.linux.dev, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] net: bridge: handle ports in locked mode for ll learning
Date: Wed, 11 Dec 2024 10:42:22 +0200	[thread overview]
Message-ID: <Z1lQblzlqCZ-3lHM@shredder> (raw)
In-Reply-To: <CAJpXRYS3Wbug0CADi_fnaLXdZng1LSicXRTxci3mwQjZmejsdQ@mail.gmail.com>

On Tue, Dec 10, 2024 at 04:28:54PM +0100, Jonas Gorski wrote:
> Thanks for the pointer. Reading the discussion, it seems this was
> before the explicit BR_PORT_MAB option and locked learning support, so
> there was some ambiguity around whether learning on locked ports is
> desired or not, and this was needed(?) for the out-of-tree(?) MAB
> implementation.

There is a use case for learning on a locked port even without MAB. If
user space is granting access via dynamic FDB entires, then you need
learning enabled to refresh these entries.

> But now that we do have an explicit flag for MAB, maybe this should be
> revisited? Especially since with BR_PORT_MAB enabled, entries are
> supposed to be learned as locked. But link local learned entries are
> still learned unlocked. So no_linklocal_learn still needs to be
> enabled for +locked, +learning, +mab.

I mentioned this in the man page and added "no_linklocal_learn" to
iproute2, but looks like it is not enough. You can try reposting the
original patch (skip learning from link-local frames on a locked port)
with a Fixes tag and see how it goes. I think it is unfortunate to
change the behavior when there is already a dedicated knob for what you
want to achieve, but I suspect the change will not introduce regressions
so maybe people will find it acceptable.

  reply	other threads:[~2024-12-11  8:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-10 14:06 [PATCH RFC] net: bridge: handle ports in locked mode for ll learning Jonas Gorski
2024-12-10 14:34 ` Vladimir Oltean
2024-12-10 14:47   ` Jonas Gorski
2024-12-10 14:55     ` Vladimir Oltean
2024-12-10 15:28       ` Jonas Gorski
2024-12-11  8:42         ` Ido Schimmel [this message]
2024-12-11 10:32           ` Jonas Gorski
2024-12-11 14:50             ` Ido Schimmel
2024-12-12  9:50               ` Jonas Gorski
2024-12-12 12:25                 ` Ido Schimmel
2024-12-13 11:25                   ` Jonas Gorski
2024-12-15  9:35                     ` Ido Schimmel

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=Z1lQblzlqCZ-3lHM@shredder \
    --to=idosch@nvidia.com \
    --cc=bridge@lists.linux.dev \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=jonas.gorski@bisdn.de \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@kapio-technology.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=razor@blackwall.org \
    --cc=roopa@nvidia.com \
    --cc=schultz.hans@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 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.