Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sun, 21 Aug 2022 10:08:04 +0300
From:   Ido Schimmel <idosch@nvidia.com>
To:     netdev@kapio-technology.com
Cc:     Vladimir Oltean <olteanv@gmail.com>, davem@davemloft.net,
        kuba@kernel.org, netdev@vger.kernel.org,
        Andrew Lunn <andrew@lunn.ch>,
        Vivien Didelot <vivien.didelot@gmail.com>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Eric Dumazet <edumazet@google.com>,
        Paolo Abeni <pabeni@redhat.com>, Jiri Pirko <jiri@resnulli.us>,
        Ivan Vecera <ivecera@redhat.com>,
        Roopa Prabhu <roopa@nvidia.com>,
        Nikolay Aleksandrov <razor@blackwall.org>,
        Shuah Khan <shuah@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        linux-kernel@vger.kernel.org, bridge@lists.linux-foundation.org,
        linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry
 flag to drivers
Message-ID: <YwHZ1J9DZW00aJDU@shredder>
References: <5a4cfc6246f621d006af69d4d1f61ed1@kapio-technology.com>
 <YvkM7UJ0SX+jkts2@shredder>
 <34dd1318a878494e7ab595f8727c7d7d@kapio-technology.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <34dd1318a878494e7ab595f8727c7d7d@kapio-technology.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?iEROivNvcCuYgmdFzJSHQ1IKqU6JJxXtIeswS5cAIn+i30DMMRF92OYauj5N?=
 =?us-ascii?Q?C2eB135YcDlTFXz5YCRN0otSWUqv2hSE1MS9dHVjb1SSyttPN7+UgQ1dR1Xx?=
 =?us-ascii?Q?tb5pXVftfMr5uWNN7pu4VDT8kMqqjTn0NyJTiyTpEv/eIhGVzC0gsYZzy1iD?=
 =?us-ascii?Q?MKAcj90sUaNVPBLY5jHk2g4Fgct0+Du1/3Jn1b7St6+tuxqDPhiTnZgJwHoz?=
 =?us-ascii?Q?yJaZDDHRYvjCAYlo4j+asrClUOR7pT2fnn6ThpHGjTZ6t8oskd2NprvnFe4y?=
 =?us-ascii?Q?O8YJm8cw5WzCiyt2MdApVxZuj+97tBwerU8JaCb0MYQ8bOFvlmhT66OwSp6j?=
 =?us-ascii?Q?SVpEzxZe04ENvYTGYdznUGuTFIOz0ZetmSOExvguw+Exa8q5GloeiudlHwhv?=
 =?us-ascii?Q?/xrheNvClPSmJ0vYNezaQTljgdx+AmvjDxQI/5Eg4ezWTUBIBoe5jBjPuf+8?=
 =?us-ascii?Q?7F6ijk2+gqKywrQbA2zRV1wQH8xCpu6iKJmO75NvenPS1CFgVfO+rM70IMjl?=
 =?us-ascii?Q?yPHs8nc0u24PhZ98DbmwrDSumqaQiq5xv2aATNDHC0xPzAme0QazF2HeolQy?=
 =?us-ascii?Q?6FWcVCZ5pjVd7foipT7ply8F6m873X25U5QlBOWuH/NKWJHD8+5qf9T+z/Qx?=
 =?us-ascii?Q?A69RqqNgLP4QSQudfKyJMsdFuw3ggm39VZeqg0lZIIVSxAVyVye9d1q+tfDb?=
 =?us-ascii?Q?2feN5L6UIeMtuqfonYPRuirmTnpwekTY8B3OUJY9XulZn1GU2NblWmVFhqo8?=
 =?us-ascii?Q?lhKE7KHFCrnvtVQ8F3GfNSqBaM0FW8Zb/9fq7v2pCVaARiZgUoJ7Z5Lig+kz?=
 =?us-ascii?Q?s/RQgsE/YM39+tWfTeSLpS7YNEQWY+7JCKayNGO1Kdfr6/PKMk4d2s9a9GmL?=
 =?us-ascii?Q?Yw9QpiGSCFE3TtLwdh2vTwXR5yUQr1DvvAyeXQRQ0Lv0o4uTlVLCcrO4gqwS?=
 =?us-ascii?Q?ROJECUzP7JuaAxEIQrdxJFFlVALH+zEi7otMjWBi32pfsT90CC17XdjYOf/m?=
 =?us-ascii?Q?yH2rU1X31eDnG8LzPp+kx1haMhtTcArAHHodJ4dlLsWxS50aeoT4zdjJ83+p?=
 =?us-ascii?Q?GfAYTPdaSp+tyUNPmaOrFtvEJCWzIA209eQJZh9MWBHck1b82HgnRZ69Ctju?=
 =?us-ascii?Q?Xt4GX5svA3kbWqcxVCowg8EZRX19egOTPB91zXRkQl49RIK0vTFd52sMaHx4?=
 =?us-ascii?Q?EjLevL86toJP3VufYO2dWrR7JLm6gU96yu+NATh8YqBtbeNPKl/Gvr2Zua1u?=
 =?us-ascii?Q?6ZKj57M8L2BEXGqmk3zdmAWzFsTCQ6OKFt1qLrNMA4lkpoR9u7/M97MAzCoZ?=
 =?us-ascii?Q?dtG+G73fQUaWD+Ezp9p9AVYWZwB76F7dxkLB+Jj5WJKUt5cSdeJqB8vw3LMJ?=
 =?us-ascii?Q?1qITgQWHIil/q5ikkiSz+/cVkIrQEAUwixp5bxb5Wt++B9FY6q1Dn2kMzOZj?=
 =?us-ascii?Q?JTyXwoQLzIBiZMq7Dqwp2mAAHKUimC+QneXvdV6E/Tvj9TmaWvh7F7fVT9OZ?=
 =?us-ascii?Q?7UUcYZiVOup4x7IVrWsuVXx7nRrW4B3jvnaxpihO7y4tkCoAyaQC9iT3LSv0?=
 =?us-ascii?Q?SWgsWIl0o+RT7Lzf2H49f1GZEZmj1e4fRx2DHTQ+?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ca2c8474-d42f-4911-375e-08da8343e711
X-MS-Exchange-CrossTenant-AuthSource: IA1PR12MB6163.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Aug 2022 07:08:08.9996
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: dDLK76gGfUtqHgacaUz9OLMM/gVB6EiDmC1WLLR/8gttOLVu0Cpqrvi8wSPu8ooLbAIcdaosUjlyYdqppuiSBA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4036
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        SPF_HELO_PASS,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Aug 19, 2022 at 11:51:11AM +0200, netdev@kapio-technology.com wrote:
> On 2022-08-14 16:55, Ido Schimmel wrote:
> > On Fri, Aug 12, 2022 at 02:29:48PM +0200, netdev@kapio-technology.com
> > wrote:
> > > On 2022-08-11 13:28, Ido Schimmel wrote:
> > > 
> > > > > > I'm talking about roaming, not forwarding. Let's say you have a locked
> > > > > > entry with MAC X pointing to port Y. Now you get a packet with SMAC X
> > > > > > from port Z which is unlocked. Will the FDB entry roam to port Z? I
> > > > > > think it should, but at least in current implementation it seems that
> > > > > > the "locked" flag will not be reset and having locked entries pointing
> > > > > > to an unlocked port looks like a bug.
> 
> I have made the locked entries sticky in the bridge, so that they don't move
> to other ports.

Please make sure that this design choice is explained in the commit
message. To be clear, it cannot be "this is how device X happens to
work".

> 
> > > > > >
> > > > >
> > > 
> > > In general I have been thinking that the said setup is a network
> > > configuration error as I was arguing in an earlier conversation with
> > > Vladimir. In this setup we must remember that SMAC X becomes DMAC X
> > > in the
> > > return traffic on the open port. But the question arises to me why
> > > MAC X
> > > would be behind the locked port without getting authed while being
> > > behind an
> > > open port too?
> > > In a real life setup, I don't think you would want random hosts
> > > behind a
> > > locked port in the MAB case, but only the hosts you will let
> > > through. Other
> > > hosts should be regarded as intruders.
> > > 
> > > If we are talking about a station move, then the locked entry will
> > > age out
> > > and MAC X will function normally on the open port after the timeout,
> > > which
> > > was a case that was taken up in earlier discussions.
> > > 
> > > But I will anyhow do some testing with this 'edge case' (of being
> > > behind
> > > both a locked and an unlocked port) if I may call it so, and see to
> > > that the
> > > offloaded and non-offloaded cases correspond to each other, and will
> > > work
> > > satisfactory.
> > 
> > It would be best to implement these as additional test cases in the
> > current selftest. Then you can easily test with both veth pairs and
> > loopbacks and see that the hardware and software data paths behave the
> > same.
> > 
> 
> How many loops would be needed to have a selftest with a HUB and a MAC on
> both a locked and an unlocked port?

I assume you want a hub to simulate multiple MACs behind the same port.
You don't need a hub for that. You can set the MAC using mausezahn. See
'-a' option:

"
   -a <src-mac|keyword>
       Use specified source MAC address with hexadecimal notation such as 00:00:aa:bb:cc:dd.  By default the interface MAC address will be used. The  keywords  ''rand''
       and  ''own''  refer to a random MAC address (only unicast addresses are created) and the own address, respectively. You can also use the keywords mentioned below
       although broadcast-type source addresses are officially invalid.
"

> 
> > > 
> > > I think it will be good to have a flag to enable the mac-auth/MAB
> > > feature,
> > > and I suggest just calling the flag 'mab', as it is short.
> 
> I have now created the flag to enable Mac-Auth/MAB with iproute2:
> bridge link set dev DEV macauth on|off

You have 'macauth' here, but 'mab' in the output below. They need to
match. I prefer the latter unless you have a good reason to use
'macauth'.

> 
> with the example output from 'bridge -d link show dev DEV' when macauth is
> enabled:
> 1: ethX: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state
> forwarding priority 32 cost 19
>     hairpin off guard off root_block off fastleave off learning on flood off
> mcast_flood on bcast_flood on mcast_router 1 mcast_to_unicast off
> neigh_suppress off vlan_tunnel off isolated off locked mab on
> 
> The flag itself in the code is called BR_PORT_MACAUTH.
> 
> > 
> > Fine by me, but I'm not sure everyone agrees.