From:   Vladimir Oltean <vladimir.oltean@nxp.com>
To:     Horatiu Vultur <horatiu.vultur@microchip.com>
CC:     "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "kuba@kernel.org" <kuba@kernel.org>,
        "robh+dt@kernel.org" <robh+dt@kernel.org>,
        "UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>,
        "linux@armlinux.org.uk" <linux@armlinux.org.uk>,
        "f.fainelli@gmail.com" <f.fainelli@gmail.com>,
        "vivien.didelot@gmail.com" <vivien.didelot@gmail.com>,
        "andrew@lunn.ch" <andrew@lunn.ch>
Subject: Re: [PATCH net-next v3 6/6] net: lan966x: Add switchdev support
Thread-Topic: [PATCH net-next v3 6/6] net: lan966x: Add switchdev support
Thread-Index: AQHX7OGqma9W7JTLPke3A5iwt0gyh6wqKbcAgAA0OYCABfZPgA==
Date:   Mon, 13 Dec 2021 11:46:05 +0000
Message-ID: <20211213114603.jdvv5htw22vd3azj@skbuf>
References: <20211209094615.329379-1-horatiu.vultur@microchip.com>
 <20211209094615.329379-7-horatiu.vultur@microchip.com>
 <20211209133616.2kii2xfz5rioii4o@skbuf>
 <20211209164311.agnofh275znn5t5c@soft-dev3-1.localhost>
In-Reply-To: <20211209164311.agnofh275znn5t5c@soft-dev3-1.localhost>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?GgpjhJ5c+6+9fb8bsADDbmsi4sjd2Jv9ycLbsErfm1bVG4AthXKfNx2p5yuG?=
 =?us-ascii?Q?5zFk3HMatGu3CFX2HTXbKJRCwrTqfHNFrLaBIe6IfnnIfVKNKCeCOKktFf6J?=
 =?us-ascii?Q?u/9aQ5+ReulmoABB3yW/0dTyNfWchp1PUNe4jKu+X6tvdfcEllVG/Z1l1EZG?=
 =?us-ascii?Q?W51XqSS296FUUdePG1MSovQNQRmKoqMf6MpEIRuzBRjkmTN6FjticaSMr+8i?=
 =?us-ascii?Q?B7Scew9GYnHrCST6yAFfufMqFLbgYmIDEQDtrB8pslVK5wdYEoG/Zchut7JT?=
 =?us-ascii?Q?ySC3KZOV2brjPHmtcXPuoVTzMdvga3RwPlK3sxicrokkIg33NLbrVZWpPob8?=
 =?us-ascii?Q?xgmh4BTp84q4YoLbYvn1+U/GFFlPqnIxdjBS/1qxIqcsct76zxnTDTaujvgw?=
 =?us-ascii?Q?GhZEZono1DS3x9W8J7482nEEr34VhQdjyWnhYs3qxZ1biXjFgJcaXxk+9H0E?=
 =?us-ascii?Q?3ivS4RHl9bvELMIgx5Os+mSDG/D6STiN/oqCzeK/VuiAHf+aXo++qz7po5XG?=
 =?us-ascii?Q?MnM97H0z7Ot2VP0hwWlYL8iEonNBdSNF2H8A7eEOnbFElrvDNUN39FIfHFWj?=
 =?us-ascii?Q?bGmB/W8cR7HtQdqIVakY9nHG+Yt3OOiI7qBIqEA86vaMoxTbV78zCr0HKkMp?=
 =?us-ascii?Q?Z7IGAVIxe/E83VRktBGnaKvVDBLJMNitZehmauBWG2fpTxhn2UoEpS83G6cs?=
 =?us-ascii?Q?3mF6fx1G6xdwDcfrVHwz/TS39yiqLQ06V3DFWWvyAqUo1nTLx8dzaAkSEI1u?=
 =?us-ascii?Q?lMdZ8CDpoQ9WhfMtOzi40pLfrIRPpLnTUqZTqgd9JDDcMYOa6u2AmztaEEB8?=
 =?us-ascii?Q?mvHYQ2yC9fn8M91hWZNdpuivVnG1IU4Yh0lPWMZPXZyaTI55wsZLvF2i2Fo7?=
 =?us-ascii?Q?/1vk8mDVu2H9NIWR8ffpMaxoe8toWGx0QCT7Iqdo05VCVCrBu7nRwHAUgtyF?=
 =?us-ascii?Q?A16lGrvNYjegjbDXKlI2BzBK/jNuXLC5+P0Esw8BjvpMd7Ttvo7WXaDKvRur?=
 =?us-ascii?Q?i0FzeWErA+Q6S7E3pi5Lev9FDIySf3e3P6d/eRvyiWpAEcGrOG/pkA5ZEg7g?=
 =?us-ascii?Q?x+KvSFRsxPSfyGRqK77FzZ3pH9jmZWRSQVfrzV5IuPoW7ZN7gp/Y7F4WzRqu?=
 =?us-ascii?Q?ZhXCVF9CmArqBOGnBj3sSgLGkp3qCwj0Vvi2Sh/DlOBzkFH4IZBTxF+4GeH6?=
 =?us-ascii?Q?AjMpAmBrN+bKx1Lk7cjzYjZpJRDwtzueI3XY1KpVs9KsvV8744GfHWgPJduV?=
 =?us-ascii?Q?MQ+8Uf5yEjyJbUtacOiAJGa3qRjFfLyDiRab3frOkUPzYtJMdxPrJuqwjRZR?=
 =?us-ascii?Q?LXO1O2AaApc4a4gPEY6qLPplBX099UIl1JJrS+h8HZn4EL4yRHeWuUrr4ToF?=
 =?us-ascii?Q?Vv5DwuHxMywQyreDyd8KZvo7TPbuCxMZPZwTXzQv37C4uz60lAWNf6pjdcwA?=
 =?us-ascii?Q?7Tb2NFQ/qRe6MEpa1ed+9x7O5Jik6BioEebKLwI2VgbnVLjjYM00shji+I8k?=
 =?us-ascii?Q?BgrRAYmaiERKb8d5YuAMkkr3+l1nnvzdqFCHd36i5eQ0tTKCtDURJ6zLA5Eh?=
 =?us-ascii?Q?qzD/+iS1qyVr0iWyJyuzJaS/YVrzLeWJES1bfrOLpgGISHaa02KD12U8+4OG?=
 =?us-ascii?Q?NXSEMMLwMgek1wVBqCClBDA=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <A723559F15A3124C83A082C890259669@eurprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VI1PR04MB5136.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f3e70041-e660-4548-e435-08d9be2e256c
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2021 11:46:05.4208
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: PeKPQfShXfyeh9WSZaTXUBnadR4NHAqbvewPNdEVfG7cN+NVM3+b/tWh1ikkV6q2BKhsRk6stiolygj/T5H8JQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB4685
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Dec 09, 2021 at 05:43:11PM +0100, Horatiu Vultur wrote:
> > My documentation of CPU_SRC_COPY_ENA says:
> >=20
> > If set, all frames received on this port are
> > copied to the CPU extraction queue given by
> > CPUQ_CFG.CPUQ_SRC_COPY.
> >=20
> > I think it was established a while ago that this isn't what promiscuous
> > mode is about? Instead it is about accepting packets on a port
> > regardless of whether the MAC DA is in their RX filter or not.
>=20
> Yes, I am aware that this change interprets the things differently and I
> am totally OK to drop this promisc if it is needed.

I think we just need to agree on the observable behavior. Promiscuous
means for an interface to receive packets with unknown destination, and
while in standalone mode you do support that, in bridge mode you're a
bit on the edge: the port accepts them but will deliver them anywhere
except to the CPU. I suppose you could try to make an argument that you
know better than the bridge, and as long as the use cases for that are
restricted enough, maybe it could work for most scenarios. I don't know.

> > Hence the oddity of your change. I understand what it intends to do:
> > if this is a standalone port you support IFF_UNICAST_FLT, so you drop
> > frames with unknown MAC DA. But if IFF_PROMISC is set, then why do you
> > copy all frames to the CPU? Why don't you just put the CPU in the
> > unknown flooding mask?
>=20
> Because I don't want the CPU to be in the unknown flooding mask. I want
> to send frames to the CPU only if it is required.

What is the strategy through which this driver accepts things like
pinging the bridge device over IPv6, with the Neighbor Discovery
protocol having the ICMP6 neighbor solicitation messages delivered to
(according to my knowledge) an unregistered IPv6 multicast address?
Whose responsibility is it to notify the driver of that address, and
does the driver copy those packets to the CPU in the right VLAN?

> > How do you handle migration of an FDB entry pointing towards the CPU,
> > towards one pointing towards a port?
>=20
> Shouldn't I get 2 calls that the entry is removed from CPU and then
> added to a port?

Ok.=