Re: [PATCH v4 10/10] bnxt: Create an auxiliary device for fwctl_bnxt

[Saeed Mahameed <saeedm@nvidia.com>]

On 07 Feb 07:36, Jakub Kicinski wrote:
>On Thu, 6 Feb 2025 22:17:58 -0500 Andy Gospodarek wrote:
>> On Thu, Feb 6, 2025 at 7:44 PM Jakub Kicinski <kuba@kernel.org> wrote:
>> > On Thu,  6 Feb 2025 20:13:32 -0400 Jason Gunthorpe wrote:
>> > > From: Andy Gospodarek <gospo@broadcom.com>
>> > >
>> > > Signed-off-by: Andy Gospodarek <gospo@broadcom.com>
>> > > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
>> >
>> > This is only needed for RDMA, why can't you make this part of bnxt_re ?
>>
>> This is not just needed for RDMA, so having the aux device for fwctl
>> as part of the base driver is preferred.
>
>Please elaborate. As you well know I have experience using Broadcom
>devices in large TCP/IP networks, without the need for proprietary
>tooling.
>

I think Andy was referring to the fact that the aux bus management is
implemented in the base driver which is currently under netdev stack.
fwctl as well as netdev/RDMA are aux drivers sharing the same base "pci"
device. So it's not part of netdev TCP/IP, due to fact that the pci base
driver is part of netdev due to historical reasons, driver developers
have to go through netdev mailing list to review pci/bus/aux device driver
patches, which has nothing to do with TCP/IP. If netdev doesn't welcome
non-TCP/IP patches, then I think we have a bigger problem here..

>Now, I understand that it may be expedient for Broadcom and nVidia
>to skip the upstream process and ship "features" to customers using
>DOCA and whatever you call your tooling. But let's be honest that
>this is the motivation here. Unified support for proprietary tooling

DOCA doesn't need FWCTL.
DOCA and DPDK has all the support they need to configure the pipeline 
and their own transport without FWCTL. This patchset has nothing
to do with DOCA, this is pretty clear from mutli vendor and
corss-kernel support for FWCTL.

>across subsystems and product lines for a given vendor. This way
>migrating from in-tree networking to proprietary IPU/DPU networking
>is easier, while migrating to another vendor would require full tooling
>replacement.

This is old netdev mentality, we must not apply it to all subsystems.
And I don't understand why tooling has to be standardized in-kernel-tree?
We have plans to standardize tooling in user-space, this was already very
successfully done in the nvme-cli..

>
>I have nothing against RDMA and CXL subsystems adding whatever APIs
>they want. But I don't understand why you think it's okay to force
>this on normal networking, which does not need it.
>

As explained above, netdev doesn't need it, but netdev subsystem also hosts
the pci base drivers, so you are going to see fwctl patches the same as you
see rdma and other non netdev patches flowing through netdev ML.

>nVidia is already refusing to add basic minoring features to their
>upstream driver, and keeps asking its customers to migrate to libdoca.
nVidia is one of the top contributers to netdev, we submit patches on
weekly bases and due to netdev mailing list review backlog and policy
we barely make quota, so please elaborate on what features we are refusing
to do ??

>So the concern that merging this will negatively impact standard
>tooling is no longer theoretical.
>
>Anyway, rant over. Give us some technical details.
Technical details: Driver specific aux subsystem implementation is base 
driver responsibility which is hosted under netdev.