netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Nikolay Aleksandrov <nikolay@nvidia.com>
Cc: Tobias Waldekranz <tobias@waldekranz.com>,
	davem@davemloft.net, kuba@kernel.org, andrew@lunn.ch,
	vivien.didelot@gmail.com, f.fainelli@gmail.com, roopa@nvidia.com,
	netdev@vger.kernel.org, jiri@resnulli.us, idosch@idosch.org,
	stephen@networkplumber.org
Subject: Re: [RFC net-next 2/7] net: bridge: switchdev: Include local flag in FDB notifications
Date: Tue, 19 Jan 2021 00:06:16 +0200	[thread overview]
Message-ID: <20210118220616.ql2i3uigyz6tiuhz@skbuf> (raw)
In-Reply-To: <4fb95388-9564-7555-06c0-3126f95c34b3@nvidia.com>

On Mon, Jan 18, 2021 at 11:53:18PM +0200, Nikolay Aleksandrov wrote:
> On 18/01/2021 23:50, Vladimir Oltean wrote:
> > On Mon, Jan 18, 2021 at 11:39:27PM +0200, Nikolay Aleksandrov wrote:
> >> Apologies for the multiple emails, but wanted to leave an example:
> >>
> >> 00:11:22:33:44:55 dev ens16 master bridge permanent
> >>
> >> This must always exist and user-space must be able to create it, which
> >> might be against what you want to achieve (no BR_FDB_LOCAL entries with
> >> fdb->dst != NULL).
> >
> > Can you give me an example of why it would matter that fdb->dst in this
> > case is set to ens16?
> >
>
> Can you dump it as "dev ens16" without it? :)
> Or alternatively can you send a notification with "dev ens16" without it?
>
> I'm in favor of removing it, but it is risky since some script somewhere might
> be searching for it, or some user-space daemon might expect to see a notification
> for such entries and react on it.

If "dev ens16" makes no difference to the forwarding and/or termination
path of the bridge, just to user space reporting, then keeping
appearances is a bit pointless.

For example, DSA switch interfaces inherit by default the MAC address of
the host interface. Having multiple net devices with the same MAC
address works because either they are in different L2 domains (case in
which the MAC addresses should still be unique per domain), or they are
in the same L2 domain, under the same bridge (case in which it is the
bridge who should do IP neighbour resolution etc).
Having that said, let there be these commands:

$ ip link add br0 type bridge
$ ip link set swp0 master br0
$ ip link set swp1 master br0
$ ip link set swp2 master br0
$ ip link set swp3 master br0
$ bridge fdb | grep permanent
00:04:9f:05:de:0a dev swp0 vlan 1 master br0 permanent
00:04:9f:05:de:0a dev swp0 master br0 permanent

And these:

$ ip link add br0 type bridge
$ ip link set swp3 master br0
$ ip link set swp2 master br0
$ ip link set swp1 master br0
$ ip link set swp0 master br0
$ bridge fdb | grep permanent
00:04:9f:05:de:0a dev swp0 vlan 1 master br0 permanent
00:04:9f:05:de:0a dev swp0 master br0 permanent
00:04:9f:05:de:0a dev swp3 vlan 1 master br0 permanent
00:04:9f:05:de:0a dev swp3 master br0 permanent

Preserving the reporting for permanent/local FDB entries added by user
is one thing. But do we need to also preserve this behavior (i.e. report
the first unique MAC address of an interface that joins the bridge as a
permanent/local address on that brport, but not on the others, and not
on br0)? If yes, then I'm afraid there's nothing we can do.

  reply	other threads:[~2021-01-18 22:07 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-16  1:25 [RFC net-next 0/7] net: dsa: Sync local bridge FDB addresses to hardware Tobias Waldekranz
2021-01-16  1:25 ` [RFC net-next 1/7] net: bridge: switchdev: Refactor br_switchdev_fdb_notify Tobias Waldekranz
2021-01-17 17:24   ` Vladimir Oltean
2021-01-16  1:25 ` [RFC net-next 2/7] net: bridge: switchdev: Include local flag in FDB notifications Tobias Waldekranz
2021-01-17 19:30   ` Vladimir Oltean
2021-01-18 18:58     ` Tobias Waldekranz
2021-01-18 19:27       ` Vladimir Oltean
2021-01-18 20:19         ` Tobias Waldekranz
2021-01-18 21:03           ` Vladimir Oltean
2021-01-18 21:17           ` Nikolay Aleksandrov
2021-01-18 21:22             ` Nikolay Aleksandrov
2021-01-18 21:39               ` Nikolay Aleksandrov
2021-01-18 21:50                 ` Vladimir Oltean
2021-01-18 21:53                   ` Nikolay Aleksandrov
2021-01-18 22:06                     ` Vladimir Oltean [this message]
2021-01-18 22:09                       ` Vladimir Oltean
2021-01-18 22:42                       ` Nikolay Aleksandrov
2021-01-19  0:42                         ` Vladimir Oltean
2021-01-19 10:14                           ` Nikolay Aleksandrov
2021-01-18 19:28     ` Ido Schimmel
2021-01-16  1:25 ` [RFC net-next 3/7] net: bridge: switchdev: Send FDB notifications for host addresses Tobias Waldekranz
2021-01-18 11:28   ` Vladimir Oltean
2021-01-16  1:25 ` [RFC net-next 4/7] net: dsa: Include local addresses in assisted CPU port learning Tobias Waldekranz
2021-01-16  1:25 ` [RFC net-next 5/7] net: dsa: Include bridge " Tobias Waldekranz
2021-01-16  1:25 ` [RFC net-next 6/7] net: dsa: Sync static FDB entries on foreign interfaces to hardware Tobias Waldekranz
2021-01-16  1:25 ` [RFC net-next 7/7] net: dsa: mv88e6xxx: Request assisted learning on CPU port Tobias Waldekranz
2021-02-01  6:24 ` DENG Qingfang
2021-02-03  9:27   ` Tobias Waldekranz
2021-02-03 10:14     ` Vladimir Oltean
2021-02-03 10:42       ` Tobias Waldekranz

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=20210118220616.ql2i3uigyz6tiuhz@skbuf \
    --to=olteanv@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=idosch@idosch.org \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nikolay@nvidia.com \
    --cc=roopa@nvidia.com \
    --cc=stephen@networkplumber.org \
    --cc=tobias@waldekranz.com \
    --cc=vivien.didelot@gmail.com \
    --subject='Re: [RFC net-next 2/7] net: bridge: switchdev: Include local flag in FDB notifications' \
    /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

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).