From: Nikolay Aleksandrov <nikolay@nvidia.com>
To: "vladimir.oltean@nxp.com" <vladimir.oltean@nxp.com>
Cc: "idosch@idosch.org" <idosch@idosch.org>,
"bridge@lists.linux-foundation.org"
<bridge@lists.linux-foundation.org>,
"davem@davemloft.net" <davem@davemloft.net>,
"andrew@lunn.ch" <andrew@lunn.ch>,
"vivien.didelot@gmail.com" <vivien.didelot@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"jiri@mellanox.com" <jiri@mellanox.com>,
"kuba@kernel.org" <kuba@kernel.org>,
Roopa Prabhu <roopa@nvidia.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"f.fainelli@gmail.com" <f.fainelli@gmail.com>
Subject: Re: [RFC PATCH] net: bridge: multicast: add support for L2 entries
Date: Sun, 25 Oct 2020 10:49:46 +0000 [thread overview]
Message-ID: <c6b2a63f635d57bd34bb96bbc4deecb506968314.camel@nvidia.com> (raw)
In-Reply-To: <20201025065957.5736elloorffcdif@skbuf>
On Sun, 2020-10-25 at 06:59 +0000, Vladimir Oltean wrote:
> On Wed, Oct 21, 2020 at 09:17:07AM +0000, Nikolay Aleksandrov wrote:
> > > diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h
> > > index 4c687686aa8f..a25f6f9aa8c3 100644
> > > --- a/include/uapi/linux/if_bridge.h
> > > +++ b/include/uapi/linux/if_bridge.h
> > > @@ -520,12 +520,14 @@ struct br_mdb_entry {
> > > #define MDB_FLAGS_FAST_LEAVE (1 << 1)
> > > #define MDB_FLAGS_STAR_EXCL (1 << 2)
> > > #define MDB_FLAGS_BLOCKED (1 << 3)
> > > +#define MDB_FLAGS_L2 (1 << 5)
> >
> > I think this should be 4.
> >
>
> Shouldn't this be in sync with MDB_PG_FLAGS_L2 though? We also have
> MDB_PG_FLAGS_BLOCKED which is BIT(4).
Unfortunately they haven't been in sync from the start. MDB_FLAGS bit
0 is offload, while MDB_PG_FLAGS bit 0 is permanent. As you can see
here blocked is bit 3, while internally it's 4 due to the same reason.
We can't afford to skip 1 bit since this is uAPI and we only got 8
available bits. I wonder if we need these L2 bits at all, why not use
only proto == 0 to denote it's a L2 entry? I can't remember why I added
the bits back then, but until now proto == 0 wasn't allowed and the
kernel couldn't export it as such, so it seems possible to use it.
prev parent reply other threads:[~2020-10-25 10:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-17 18:41 [RFC PATCH] net: bridge: multicast: add support for L2 entries Vladimir Oltean
2020-10-21 9:17 ` Nikolay Aleksandrov
2020-10-21 9:25 ` Nikolay Aleksandrov
2020-10-25 6:59 ` Vladimir Oltean
2020-10-25 7:42 ` Vladimir Oltean
2020-10-25 10:49 ` Nikolay Aleksandrov [this message]
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=c6b2a63f635d57bd34bb96bbc4deecb506968314.camel@nvidia.com \
--to=nikolay@nvidia.com \
--cc=andrew@lunn.ch \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=idosch@idosch.org \
--cc=jiri@mellanox.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=roopa@nvidia.com \
--cc=vivien.didelot@gmail.com \
--cc=vladimir.oltean@nxp.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;
as well as URLs for NNTP newsgroup(s).