From: Nikolay Aleksandrov <firstname.lastname@example.org> To: Vladimir Oltean <email@example.com> Cc: Tobias Waldekranz <firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org> Subject: Re: [RFC net-next 2/7] net: bridge: switchdev: Include local flag in FDB notifications Date: Tue, 19 Jan 2021 12:14:20 +0200 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <20210119004200.eocv274y2qbemp63@skbuf> On 19/01/2021 02:42, Vladimir Oltean wrote: > On Tue, Jan 19, 2021 at 12:42:04AM +0200, Nikolay Aleksandrov wrote: >> No, it shouldn't be a problem to change that. We should be careful about the >> way it's changed though because reporting it for all ports might become a scale >> issue with 4k vlans, and also today you can't add the same mac for multiple ports. >> Perhaps the best way is to report it for the bridge itself, while still allowing >> such entries to be added/deleted by user-space. > > I think what Tobias is trying to achieve is: > (a) offload the locally terminated FDB addresses through switchdev, in a > way that is not "poisoned", i.e. the driver should not be forced to > recognize these entries based on the is_local flag. This includes > the ports MAC addresses which are currently notified as is_local and > with fdb->dst = source brport (not NULL). > (b) remain compatible with the mistakes of the past, i.e. DSA and > probably other switchdev users will have to remain oblivious of the > is_local flag. So we will still have to accept "bridge fdb add > 00:01:02:03:04:05 dev swp0 master local", and it will have to keep > incorrectly installing a front-facing static FDB entry on swp0 > instead of a local/permanent one. > > In terms of implementation, this would mean that for added_by_user > entries, we keep the existing notifications broken as they are. > Whereas for !added_by_user, we replace them as much as possible with > "fdb->dst == NULL" entries (i.e. for br0). > > I haven't looked closely at the code, and I hope that this will not > happen, but maybe some of these addresses will inevitably have to be > duplicated with is_local addresses that were previously notified. In > that case I'm thinking there must be some hackery to always offload the > addresses in this order: first the is_local address, then the br0 > address, to allow the bad entry to be overwritten with the good one. > > Finally, we should modify the bridge manpage to say "we know that the > local|permanent flag is added by default, but it's deprecated so pls > don't use it anymore, just use fdb on br0". > > How does this sound? > We'll be supporting it forever, I don't see how it's being deprecated. :) Either way I'm ok with the above, but I'll be able to comment further when I see how exactly the code would change. We should be very careful not to break someone who uses these entries in a way we can't think of, for example we use permanent user-space added entries combined with ext_learn for mlag purposes which is a stranger use case, granted it won't be broken by the above. Perhaps we should consider making the new behaviour optional instead, then we can completely switch between the two modes and drop compatibility.
next prev parent reply other threads:[~2021-01-19 13:49 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 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 [this message] 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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).