Re: [PATCH v5 0/8] Introduce fwctl subystem

[Jason Gunthorpe <jgg@nvidia.com>]

On Mon, Mar 03, 2025 at 05:53:58PM -0800, Jakub Kicinski wrote:
> On Thu, 27 Feb 2025 20:26:28 -0400 Jason Gunthorpe wrote:
> > v5:
> >  - Move hunks between patches to make more sense
> >  - Rename ucmd_buffer to fwctl_ucmd_buffer
> >  - Update comments and commit messages
> >  - Copyright to 2025
> >  - Drop bxnt WIP patches
> >  - Allow a NULL ops->info
> >  - Decode more op codes for mlx5 and the sub-operation for
> >    MLX5_CMD_OP_ACCESS_REG/_USER
> 
> Did you address my feedback? I asked for the mlx5 support to only be
> enabled in RDMA is in use. Saeed who wrote the mlx5 parts of this
> patchset clearly admitted on v4:

I never agreed to that formulation. I suggested that perhaps runtime
configurations where netdev is the only driver using the HW could be
disabled (ie a netdev exclusion, not a rdma inclusion).

However, there is not agreement on this from Saeed who is responsible
for mlx5:

 https://lore.kernel.org/all/Z7z0ADkimCkhr7Xz@x130/

I also surveyed other stakeholders on a netdev-exclusion proposal and
did not hear support. You need to convince people this is a good idea.

However, I would agree fwctl should not accept any fwctl drivers for
simple networking devices. However, "smart nics" and RDMA capable
devices are in-scope.

I could also probably agree to using kconfig to disable fwctl drivers
on kernels that statically compile out rdma, vdpa, nvme and related,
though I agree with Saeed that it seems to lack technical merit.

> Greg, I've been asking for this interface to be scoped to when RDMA
> (/CXL/storage) is in enabled on these NICs since pretty much the first
> RFC. 

You only started asking for this more limited approach in v4. All your
previous arguments were that fwctl should be entirely killed for any
networking HW.

Jason