[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f2ac33e7b8ec0fefa48fe7cd3b1004abab67dcb1.camel@alliedtelesis.co.nz>
Date: Sun, 24 Nov 2024 21:01:46 +0000
From: Elliot Ayrey <Elliot.Ayrey@...iedtelesis.co.nz>
To: "andrew@...n.ch" <andrew@...n.ch>, "olteanv@...il.com"
<olteanv@...il.com>, "davem@...emloft.net" <davem@...emloft.net>,
"razor@...ckwall.org" <razor@...ckwall.org>, "pabeni@...hat.com"
<pabeni@...hat.com>, "roopa@...dia.com" <roopa@...dia.com>,
"edumazet@...gle.com" <edumazet@...gle.com>, "f.fainelli@...il.com"
<f.fainelli@...il.com>, "horms@...nel.org" <horms@...nel.org>,
"kuba@...nel.org" <kuba@...nel.org>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"bridge@...ts.linux.dev" <bridge@...ts.linux.dev>
Subject: Re: [RFC net-next (resend) 1/4] net: bridge: respect sticky flag on
external learn
On Sat, 2024-11-09 at 15:32 +0200, Nikolay Aleksandrov wrote:
> So you have a sticky fdb entry added, but it is still allowed to roam
> in HW?
No the hardware has informed us a host has _tried_ to roam.
As I think about this more, using the sticky bit alone probably isn't
the best idea and it might be better if this mechanism were related to
a port being locked? After all the port being locked in hardware is
what generates this event.
Powered by blists - more mailing lists