From: Andrew Lunn <andrew@lunn.ch>
To: Elliot Ayrey <elliot.ayrey@alliedtelesis.co.nz>
Cc: "David S . Miller" <davem@davemloft.net>,
Florian Fainelli <f.fainelli@gmail.com>,
Vladimir Oltean <olteanv@gmail.com>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Roopa Prabhu <roopa@nvidia.com>,
Nikolay Aleksandrov <razor@blackwall.org>,
Simon Horman <horms@kernel.org>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
bridge@lists.linux.dev
Subject: Re: [RFC net-next (resend) 2/4] net: bridge: send notification for roaming hosts
Date: Fri, 8 Nov 2024 14:42:18 +0100 [thread overview]
Message-ID: <93e02466-b4a0-48fd-beb0-c93b1008ff08@lunn.ch> (raw)
In-Reply-To: <20241108035546.2055996-3-elliot.ayrey@alliedtelesis.co.nz>
> This is achieved by temporarily updating the fdb entry with the new
> port, setting a new notify roaming bit, firing off a notification, and
> restoring the original port immediately afterwards. The port remains
> unchanged, respecting the sticky flag, but userspace is now notified
> of the new port the host was seen on.
This sounds a bit hacky. Could you add a new optional attribute to the
netlink message indicating the roam destination, so there is no need
to play games with the actual port?
I'm not too deep into how these all works, but i also wounder about
backwards compatibility. Old code which does not look for
FDB_NOTIFY_ROAMING_BIT is going to think it really has moved, with
your code. By using a new attribute, and not changing the port, old
code just sees a notification it is on the port it always was on,
which is less likely to cause issues?
And do we want to differentiate between it wants to roam, but the
sticky bit has stopped that, and it really has roamed?
Andrew
next prev parent reply other threads:[~2024-11-08 13:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-08 3:55 [RFC net-next (resend) 0/4] Send notifications " Elliot Ayrey
2024-11-08 3:55 ` [RFC net-next (resend) 1/4] net: bridge: respect sticky flag on external learn Elliot Ayrey
2024-11-24 21:01 ` Elliot Ayrey
2024-11-24 22:01 ` Nikolay Aleksandrov
2024-11-08 3:55 ` [RFC net-next (resend) 2/4] net: bridge: send notification for roaming hosts Elliot Ayrey
2024-11-08 13:42 ` Andrew Lunn [this message]
2024-11-24 21:32 ` Elliot Ayrey
2024-11-24 21:23 ` Elliot Ayrey
2024-11-24 21:39 ` Andrew Lunn
2024-11-24 21:57 ` Nikolay Aleksandrov
2024-11-08 3:55 ` [RFC net-next (resend) 3/4] net: dsa: mv88e6xxx: handle member-violations Elliot Ayrey
2024-11-08 13:49 ` Andrew Lunn
2024-11-11 4:39 ` Elliot Ayrey
2024-11-08 3:55 ` [RFC net-next (resend) 4/4] net: dsa: mv88e6xxx: cache fid-to-vid association Elliot Ayrey
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=93e02466-b4a0-48fd-beb0-c93b1008ff08@lunn.ch \
--to=andrew@lunn.ch \
--cc=bridge@lists.linux.dev \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=elliot.ayrey@alliedtelesis.co.nz \
--cc=f.fainelli@gmail.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=razor@blackwall.org \
--cc=roopa@nvidia.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
all inboxes | Powered by JetHome®