BlueField NIC Mode or DPU Services: What Architecture Are You Buying?

Identify who controls the network resources

NVIDIA's DOCA 3.5.0 mode guide, updated September 18, 2026, describes NIC mode as BlueField acting as a ConnectX adapter for the external host. BlueField-3's Arm cores are inactive; BlueField-2's remain active but nonfunctional. In DPU mode, the embedded Arm subsystem owns and controls NIC resources. An Arm-hosted virtual-switch control plane manages host networking.

That changes what the buyer must account for. With host-adapter behavior, the offer needs to describe the host networking result. With embedded ownership, the infrastructure design also needs to account for the Arm environment that controls those resources. The distinction concerns where control resides; a count of adapters or a nominal link rate cannot express it.

DPU and SuperNIC are also product/SKU labels. The guide lists NIC mode as the shipping default for BlueField-3 SuperNIC SKUs and DPU mode for BlueField-2 and BlueField-3 DPU SKUs. It expressly limits the BFx H20 converged accelerator to NIC mode. Ask the OEM or integrator to identify the exact SKU, supported architecture and intended delivered mode. A family name or factory default is insufficient to describe the offered configuration.

References: [N1]

Separate host software, the embedded platform and the service

The DOCA 3.5.0 overview, updated September 1, 2026, distinguishes DOCA-Host on the server from the BlueField Software Bundle on the Arm side. The latter includes the embedded operating system, DOCA runtime components and platform firmware/boot software. A proposal saying DOCA included therefore needs to identify which software, where it is supplied and which releases the offer covers.

NVIDIA's separate DOCA Services page distinguishes base images used for runtime or development from containerized service products. That distinction matters when an offer promises storage virtualization, networking or security functions. A runtime environment supplies a basis for software to execute; the buyer still needs the selected service, its configuration for the intended use and an agreed integrated result.

Ask the supplier to connect those layers in its proposal: the supported host environment, the delivered embedded-platform release, and the named service release and dependencies. Identify what arrives installed, what additional work is included and what the customer's appointed team must provide. DPU mode alone establishes none of the application's installation, applicable software rights, configuration or acceptance.

References: [N2][N3]

Use SNAP-4 to see what a service adds

NVIDIA's SNAP-4 guide in the DOCA 3.5.0 archive, updated September 9, 2026, describes presenting networked storage to the host as an emulated local block device using NVMe or virtio-blk. The host uses its standard storage driver, while SNAP handles the connection to the backing storage. This is a different delivered function from providing a host network adapter.

The same guide says SNAP 4.x is not preinstalled in the BFB software image. It also states that BlueField-3 DPU does not require a license to run BlueField SNAP. Separate software delivery consequently does not automatically mean a separate license charge. Installation, integration and the agreed service result still need to appear in the offer; other selected products require their own applicable rights and support terms.

For a proposed SNAP service, the useful buying question is which host-visible storage function the supplier will deliver against which selected backing storage. A card inventory cannot answer that. Have the appointed storage and platform owners establish the applicable configuration and evidence for that result. This example explains the purchase mechanism; it selects no supported server/storage combination or deployment procedure.

References: [N4]

Compare two offers naming the same BlueField-3 hardware

Consider fictional offers A and B for otherwise identical servers with the same BlueField-3 SKU, adapter quantity and quoted nominal port rate. For this comparison, the supplier must establish that the exact SKU permits each proposed architecture. Neither offer represents an actual supported configuration or completed deployment.

Offer A explicitly includes NIC-mode host networking. Its stated output covers the agreed host networking integration, with any additional storage service left to the customer's appointed team. A can be a complete purchase when the customer wants that division of work. It should be assessed against that defined output.

Offer B proposes DPU mode and an Arm-side SNAP-4 service to present the customer's selected networked block storage to the host. Its price, however, covers only the same hardware and physical installation as A. It leaves the service software delivery and configuration, backing-storage integration and verification output unpriced and unassigned. The extra service name expresses an intention without buying the corresponding result.

The buyer cannot compare A and B as two prices for equivalent storage delivery. Equal hardware quantities and port rates describe common inputs; B requests an additional function. Ask B's supplier to identify the complete service scope and price, the dependencies supplied by the customer and the team responsible for returning the integrated result. If an existing customer team will deliver that function, show its work in the overall comparison rather than treating the missing line as a saving.

The proposed verification should address the intended distinction. Confirming that the host has a network interface would cover a narrower question than whether the agreed host-visible block device corresponds to the selected backing storage and satisfies the agreed service criteria. The appointed owners define that verification. This fictional comparison contains no test outcome, throughput estimate or predicted host-resource saving.

Include the embedded environment in the operating responsibility

Once the architecture is selected, ask who is responsible for the software combination throughout its intended use. A NIC-mode proposal still needs a defined host stack, device-software basis and integration output. An Arm-managed service proposal also needs an owner for the embedded operating environment and the selected service. Naming the server administrator alone leaves that additional responsibility unresolved unless it is expressly part of that team's role.

Have the OEM or integrator identify the supported combination of device firmware, embedded software, host environment and service release relevant to the offer. Ask the network, storage or security owner to define the service's intended behavior and the evidence it will accept. For ongoing operation, identify who monitors the embedded service, evaluates coordinated updates and returns it to the agreed state after a supported replacement. Initial setup and a continuing operating service can be assigned differently, but each needs an explicit owner.

Compare the total work needed for the chosen result. A host-adapter offer may fit a customer whose existing teams supply the required services elsewhere. An embedded-service offer may fit a design that assigns a particular function to BlueField. Neither mode is inherently the more complete purchase. Completeness follows the selected architecture, the supplied software and integration, and the responsibility the offer actually includes.

References: [N2]

Bring the selected architecture to the physical deployment inquiry

Use Leviathan's Complete Physical Infrastructure Deployment service to discuss receiving, rack integration, agreed hardware QA, onsite installation, IT cabling and physical records. Provide a nonconfidential summary of the server configuration, approved physical connections, appointed equipment/material supplier and the team receiving the installation. Include the selected architecture so that the physical scope can identify its interface to that team's work.

The network/application owners and their appointed OEM or software integrator retain architecture selection, software delivery, configuration, security and service verification. Leviathan's physical package does not include a DPU software service or establish OEM authorization. Agree the physical tasks, checks, resources and handoff separately. The service and project-inquiry links below lead to that discussion.