Re: MLX driver for host-to-ARM communication

On Thu, 13 Aug 2026 11:33:23 +0300 Tariq Toukan wrote:
> Hi,
> 
> I plan to submit a patch series introducing a new minimalist MLX 
> host-to-ARM communication driver.
> 
> Could you confirm whether this series can be submitted in parallel with 
> our regular mlx5 feature patches without conflicting with the 15-patch 
> limit?

Not really - is there a vendor that's submitting more patches just
because they have more than one driver that you know of?
Doesn't matter how you slice your code.

If you have concerns about patch volume please me reminded that since
you don't review much your patches get the time penalty for coming
from a non-reviewer. Luckily Ido is reviewing a lot so at least you
don't get the company penalty any more.

> It is to be placed in its own new directory:
> drivers/net/ethernet/mellanox/mlx5/nodnic/
> 
> Find more details below [1].
> 
> Regards,
> Tariq
> 
> 
> [1]
> net/mlx5: Introduce mlx5_nodnic driver for BF4 management PF
> 
> BlueField-4 no longer includes the RSHIM hardware that previous
> BlueField generations relied on for host-to-ARM communication. In its
> place, the firmware exposes two dedicated management PFs — one facing
> the host side and one facing the ARM side — and configures steering
> rules to loop traffic between them, enabling host-to-ARM communication
> through standard networking interfaces.
> 
> Add mlx5_nodnic, a lightweight driver for these management PFs.
> NODNIC (No DRAM NIC) is a lightweight interface intended to allow
> simple packet transmission for minimalistic drivers with a low memory
> footprint. The driver communicates with the firmware through PCI
> Vendor Specific Capability (VSC) — reads and writes over PCI config
> space, unlike mlx5_core which uses a DMA-based command interface.
> 
> Each management PF exposes a single SQ and a single RQ that share
> one CQ. The interface configures two MSI-Xs: the data MSI-X fires
> on CQEs, driving both TX and RX completions; the event MSI-X notifies
> on port state changes, where the firmware brings the port up once both
> the host and ARM sides have gone up.

This will be nacked. We nacked multiple such drivers over the years.
Most recent one not more than a year ago.

If you model the device as a network node it should be reachable via
the normal networking path. If it's a control channel - explicit
control channel APIs should be built, rather than doing pretend
networking.

Every IPU vendor gets to this sort of design sooner or later because
it's an easy hack when running a user space SDK. nVidia has clearly
turned from upstream work to pushing your DOCA stack on all customers.
No matter how many shameful lies y'all told about fwctl not being DOCA
related. This is just a next step. But please commence your bullying
campaign. What do I know, right?