public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Bloch <mbloch@nvidia.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Tariq Toukan <tariqt@nvidia.com>,
	Leon Romanovsky <leon@kernel.org>, Jason Gunthorpe <jgg@ziepe.ca>,
	Saeed Mahameed <saeedm@nvidia.com>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org,
	netdev@vger.kernel.org, Gal Pressman <gal@nvidia.com>,
	Dragos Tatulea <dtatulea@nvidia.com>,
	Moshe Shemesh <moshe@nvidia.com>, Shay Drory <shayd@nvidia.com>,
	Alexei Lazar <alazar@nvidia.com>
Subject: Re: [PATCH mlx5-next 8/8] {net/RDMA}/mlx5: Add LAG demux table API and vport demux rules
Date: Tue, 10 Mar 2026 08:05:39 +0200	[thread overview]
Message-ID: <020de4ef-17bc-43a3-83e0-469073ffa22b@nvidia.com> (raw)
In-Reply-To: <20260309143320.1cee163d@kernel.org>



On 09/03/2026 23:33, Jakub Kicinski wrote:
> On Sun, 8 Mar 2026 20:34:26 +0200 Mark Bloch wrote:
>> Thanks for catching this. We’ll address it.
>>
>> Also, I saw IA flagged issues con
>> “net/mlx5: LAG, replace pf array with xarray”.
>> 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.
> 
> Ack, I haven't looked at the AI reivew TBH.
> As usual with known AI flags - should the explanation be part 
> of the commit message?

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.

Mason's + Claude reported 3 false positives.

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.

So in theory we could add a note like “AI tools may flag issues
X/Y/Z but those are not valid here”, but in practice it really
depends on which tool is used and how it's configured.

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.

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?

Mark





  reply	other threads:[~2026-03-10  6:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-08  6:55 [PATCH mlx5-next 0/8] mlx5-next updates 2026-03-08 Tariq Toukan
2026-03-08  6:55 ` [PATCH mlx5-next 1/8] net/mlx5: Add IFC bits for shared headroom pool PBMC support Tariq Toukan
2026-03-08  6:55 ` [PATCH mlx5-next 2/8] net/mlx5: Add silent mode set/query and VHCA RX IFC bits Tariq Toukan
2026-03-08  6:55 ` [PATCH mlx5-next 3/8] net/mlx5: LAG, replace pf array with xarray Tariq Toukan
2026-03-08  6:55 ` [PATCH mlx5-next 4/8] net/mlx5: LAG, use xa_alloc to manage LAG device indices Tariq Toukan
2026-03-08  6:55 ` [PATCH mlx5-next 5/8] net/mlx5: E-switch, modify peer miss rule index to vhca_id Tariq Toukan
2026-03-08  6:55 ` [PATCH mlx5-next 6/8] net/mlx5: LAG, replace mlx5_get_dev_index with LAG sequence number Tariq Toukan
2026-03-08  6:55 ` [PATCH mlx5-next 7/8] net/mlx5: Add VHCA RX flow destination support for FW steering Tariq Toukan
2026-03-08  6:55 ` [PATCH mlx5-next 8/8] {net/RDMA}/mlx5: Add LAG demux table API and vport demux rules Tariq Toukan
2026-03-08 15:52   ` Jakub Kicinski
2026-03-08 18:34     ` Mark Bloch
2026-03-09 21:33       ` Jakub Kicinski
2026-03-10  6:05         ` Mark Bloch [this message]
2026-03-10 23:58           ` Jakub Kicinski

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=020de4ef-17bc-43a3-83e0-469073ffa22b@nvidia.com \
    --to=mbloch@nvidia.com \
    --cc=alazar@nvidia.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=dtatulea@nvidia.com \
    --cc=edumazet@google.com \
    --cc=gal@nvidia.com \
    --cc=jgg@ziepe.ca \
    --cc=kuba@kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=moshe@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=saeedm@nvidia.com \
    --cc=shayd@nvidia.com \
    --cc=tariqt@nvidia.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