From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 60B4631A7E4; Tue, 10 Mar 2026 23:58:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773187090; cv=none; b=Vpdd7CqjmwTzLrTPO/vhL/thdnPsmTdApotUtD5d0XD0ng5qBS9ACP97DnmjLDCdlw8fdB/YjC+uCXmTB6iqbpTYTy689edMxAG876inVlA/EzgR5mxjfHpecDgrbNsgcGJVSSesj/ZL5bCTswcGqOabVcyOwnYOQge6J6om48Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773187090; c=relaxed/simple; bh=sOArtoQGyiH6UdnGufIAEk8BopJ6QZnslTNEH+JMmUY=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ajGcp44CzJR4dwYYlwn4pXUwFmYaC2GL1v/QqjAWDcyi77lhla1E+ESexpDNMTCsjdL2LGeu1oWbPEAISjaN6l/SABqlisf8KNbwbqOiO/b1USpYCL5GpFhtgCn2sqBJiM5XG5jf6uCoidWVQitB/yEBIlfSpmAfYv7Kj3GsUVU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YWyPij26; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YWyPij26" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3C84DC19423; Tue, 10 Mar 2026 23:58:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773187089; bh=sOArtoQGyiH6UdnGufIAEk8BopJ6QZnslTNEH+JMmUY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=YWyPij26+AL5mrAHWqWGaYKCVO7s8prJHb3pzvCy69M91oUIOUNFH5UkRXKJk3PWi uN8pEN7CEic2Xw5vWxZI18t7qlFwuTW7uFbP1M5YjKAypf/b8XGUw0dlIiziKkbu4b 8prrF/MYU6DjI2TM23oWpFL/hX/0fYtSCoPgy3kRJPRbMq7qI2rQj8sr03PgdYWChP p7CqRNPr4ainoradYR2n9n2R2NdJja4u4iMz67PhPJw3pg7IoEOdZ7wduKKN0zUmgS J+GHHCTsP0j7MuAaaSTFTtKmT0lW4GlivC3sxHLt186ahE4BAn3QyY2dpUZkR94uxe y0JhcRdsJM6eQ== Date: Tue, 10 Mar 2026 16:58:08 -0700 From: Jakub Kicinski To: Mark Bloch Cc: Tariq Toukan , Leon Romanovsky , Jason Gunthorpe , Saeed Mahameed , Eric Dumazet , Paolo Abeni , Andrew Lunn , "David S. Miller" , linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, netdev@vger.kernel.org, Gal Pressman , Dragos Tatulea , Moshe Shemesh , Shay Drory , Alexei Lazar Subject: Re: [PATCH mlx5-next 8/8] {net/RDMA}/mlx5: Add LAG demux table API and vport demux rules Message-ID: <20260310165808.11b88b7f@kernel.org> In-Reply-To: <020de4ef-17bc-43a3-83e0-469073ffa22b@nvidia.com> References: <20260308065559.1837449-1-tariqt@nvidia.com> <20260308065559.1837449-9-tariqt@nvidia.com> <20260308085248.2427feed@kernel.org> <20260309143320.1cee163d@kernel.org> <020de4ef-17bc-43a3-83e0-469073ffa22b@nvidia.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 10 Mar 2026 08:05:39 +0200 Mark Bloch wrote: > On 09/03/2026 23:33, Jakub Kicinski wrote: > > On Sun, 8 Mar 2026 20:34:26 +0200 Mark Bloch wrote: =20 > >> Thanks for catching this. We=E2=80=99ll address it. > >> > >> Also, I saw IA flagged issues con > >> =E2=80=9Cnet/mlx5: LAG, replace pf array with xarray=E2=80=9D. > >> Just for context, lag_lock is already a known problematic > >> area for us, and we do have plans to remove it. I ran the > >> review prompts locally in ORC mode, so I assume I saw the > >> same comments as NIPA. > >> > >> So the issue raised there is not really a new one. lag_lock > >> already has some known issues today, but we do not expect to > >> hit this particular case in practice, since by the time > >> execution reaches mdev removal, the LAG should already have > >> been destroyed and the netdevs already removed for the driver > >> internal structures. =20 > >=20 > > Ack, I haven't looked at the AI reivew TBH. > > As usual with known AI flags - should the explanation be part=20 > > of the commit message? =20 >=20 > That's an interesting question. > I'll try to give my 0.02$ about the general case. > Out of curiosity I ran one of our upcoming internal series > through both Mason's prompts with Claude and our internal > AI review tool. >=20 > Mason's + Claude reported 3 false positives. >=20 > Our internal AI tool also reported 3 false positives (interestingly, > they were different issues) and 1 real issue, which I already knew > about since the author hasn't fixed it yet. >=20 > So in theory we could add a note like =E2=80=9CAI tools may flag issues > X/Y/Z but those are not valid here=E2=80=9D, but in practice it really > depends on which tool is used and how it's configured. >=20 > At the moment it seems that netdev/NIPA is using Mason's prompts > with Claude, so if anything that would probably be the default > reference. >=20 > The larger question is that running NIPA before submission is > not currently required. Are there any plans to make that part > of the submission expectations, and not just encouraged? No, no, the process angle is not how I look at this. We should only add comments to the commit message or code if there's genuine ambiguity. Basically if someone reading the code may also get confused there should be an explanation somewhere. We should not be adding any code or explanations to make tools happy.=20