Thread (54 messages) 54 messages, 6 authors, 2022-07-08

Re: [PATCH V3 net-next 1/4] net: bridge: add fdb flag to extent locked port feature

From: Ido Schimmel <idosch@nvidia.com>
Date: 2022-06-02 10:40:06
Also in: bridge, linux-kselftest, lkml

On Thu, Jun 02, 2022 at 01:30:06PM +0300, Nikolay Aleksandrov wrote:
On 02/06/2022 13:17, Hans Schultz wrote:
quoted
On tor, jun 02, 2022 at 12:33, Nikolay Aleksandrov [off-list ref] wrote:
quoted
On 02/06/2022 12:17, Hans Schultz wrote:
quoted
On tis, maj 31, 2022 at 17:23, Ido Schimmel [off-list ref] wrote:
quoted
On Tue, May 31, 2022 at 11:34:21AM +0200, Hans Schultz wrote:
quoted
quoted
Another issue is that
bridge fdb add MAC dev DEV master static
seems to add the entry with the SELF flag set, which I don't think is
what we would want it to do or?
I don't see such thing (hacked iproute2 to print the flags before cmd):
$ bridge fdb add 00:11:22:33:44:55 dev vnet110 master static
flags 0x4

0x4 = NTF_MASTER only
I also get 0x4 from iproute2, but I still get SELF entries when I look
with:
bridge fdb show dev DEV
after the above add:
$ bridge fdb show dev vnet110 | grep 00:11
00:11:22:33:44:55 master virbr0 static
I think Hans is testing with mv88e6xxx which dumps entries directly from
HW via ndo_fdb_dump(). See dsa_slave_port_fdb_do_dump() which sets
NTF_SELF.

Hans, are you seeing the entry twice? Once with 'master' and once with
'self'?
quoted
quoted
quoted
Also the replace command is not really supported properly as it is. I
have made a fix for that which looks something like this:
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index 6cbb27e3b976..f43aa204f375 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -917,6 +917,9 @@ static int fdb_add_entry(struct net_bridge *br, struct net_bridge_port *source,
                if (flags & NLM_F_EXCL)
                        return -EEXIST;
 
+               if (flags & NLM_F_REPLACE)
+                       modified = true;
+
                if (READ_ONCE(fdb->dst) != source) {
                        WRITE_ONCE(fdb->dst, source);
                        modified = true;
The argument for always sending notifications to the driver in the case
of replace is that a replace command will refresh the entries timeout if
the entry is the same. Any thoughts on this?
I don't think so. It always updates its "used" timer, not its "updated" timer which is the one
for expire. A replace that doesn't actually change anything on the entry shouldn't generate
a notification.
Okay, so then there is missing checks on flags as the issue arose from
replacing locked entries with dynamic entries. I will do another fix
based on flags as modified needs to be true for the driver to get notified.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help