Re: MLX driver for host-to-ARM communication

[Jakub Kicinski <kuba@kernel.org>]

On Tue, 25 Aug 2026 11:24:08 +0300 Gal Pressman wrote:
> On 13/08/2026 18:14, Jakub Kicinski wrote:
> > 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?
> 
> There are some unrelated accusations here, I'll focus on the technical
> side of things.
> 
> No DRAM NIC (NODNIC) is not a new interface designed for BlueField 4 or
> DOCA. It exists in our NIC since 2015, and implemented in other OSs
> drivers long before DOCA existed.
> 
> It is a lightweight NIC PF intended for simple packet transmission with
> a small memory footprint.
> It sends and receives ordinary Ethernet frames using SQs, RQs, CQs, and
> EQs. There is no private encapsulation or command protocol. You can
> connect this PF to any other NIC on the other side of the wire and it
> will work.
> 
> On BlueField 4, the firmware connects the host side NODNIC PF to a peer
> PF on the DPU side using ordinary vport forwarding rules. The Ethernet
> packets are forwarded unchanged, both sides are Linux netdevs.
> 
> The purpose of this is to provide network connectivity between the host
> and the DPU OS, particularly when the DPU’s OOB port is not connected.
> Standard networking applications such as ssh and PXE use it.
> 
> To be clear, there is no hidden FW involvement or handling of the
> packets, these packets are forwarded as is between both sides.
> It makes sense to use a networking driver for networking purposes, I
> don't see how control channel APIs are better for this.

I understand. Having a full networking driver for such point to point
communication between device FW (/OS running on the device, doesn't
matter) complicates the system topology, config/init and mixes very
non-networking requirements with networking. It's a lazy design which
leads to poor, vendor-specific user experience. The NFP had a similar
thing, it obviously never made it upstream, but I'm very familiar with
the implications.