Summary
On a BlueField-3 B3210 in DPU mode, no traffic is ever delivered from a vport to its representor netdev, in either direction, for every vport. OVS therefore never sees a packet, and the host-to-Arm datapath does not work at all.
The eSwitch itself is demonstrably healthy. A skip_sw flower rule installs in hardware and counts exactly the packets that the representor fails to receive. The fault appears to be the FDB-miss to representor slow path specifically, not the switch.
Card: BlueField-3 B3210, P/N 900-9D3B6-00CC-A_Ax, PSID MT_0000001024
Mode: DPU mode (BF_MODE DPU mode)
Bundle: bf-bundle-3.4.0-92_26.04_ubuntu-24.04_64k_prod (DOCA 3.4.0, 64k default image)
Kernel: 6.8.0-1022-bluefield-64k — getconf PAGESIZE = 65536
MLNX OFED: MLNX_OFED_LINUX-26.04-0.8.5
NIC firmware: 32.49.1014
OVS: 3.4.0040, ovs-kernel (OVS_DOCA=“no”, dpdk_initialized false)
eSwitch: mode switchdev, inline-mode none, encap-mode basic
Steering: flow_steering_mode smfs, esw_port_metadata true
Thermal: ASIC idle at 67–69 °C
This is a fresh BFB install running the vendor-default configuration. The default ovsbr1 (p0 + pf0hpf + en3f0pf0sf0 + internal) is exactly as the bundle created it. Nothing was added, removed or reconfigured before the test below.
Minimal reproducer
Runs entirely on the Arm. No host involvement, no PCIe, no cables, and no changes to OVS.
sudo ip addr add 10.10.0.2/24 dev ovsbr1
sudo ip link set ovsbr1 up
sudo ip netns add sftest
sudo ip link set enp3s0f0s0 netns sftest # the SF’s own netdev
sudo ip netns exec sftest ip link set enp3s0f0s0 up
sudo ip netns exec sftest ip addr add 10.10.0.3/24 dev enp3s0f0s0
sudo ip netns exec sftest ping -c3 10.10.0.2
Result:
3 packets transmitted, 0 received, +3 errors, 100% packet loss
# ethtool -S en3f0pf0sf0
rx_packets: 0 ← nothing ever reaches the representor
tx_packets: 47
vport_rx_packets: 78 ← but the eSwitch counted the SF’s frames
tcpdump -nei en3f0pf0sf0 captures 0 packets. tcpdump on a netdev captures at RX, before any OVS or TC processing, so this is not OVS discarding them — the representor genuinely never receives. The same holds in reverse: the representor’s tx_packets climbs while the SF’s rx_packets stays at 0.
The eSwitch hardware is fine
On the same install, minutes apart:
sudo tc filter add dev en3f0pf0sf0 ingress protocol ip prio 3 flower skip_sw \
src_ip 10.10.0.3 action drop
sudo tc filter show dev en3f0pf0sf0 ingress
in_hw in_hw_count 1
# send exactly 30 packets from the SF, then:
sudo tc -s filter show dev en3f0pf0sf0 ingress
Sent hardware 2940 bytes 30 pkt
30 sent, 30 matched and counted in hardware. Traffic from the vport reaches the FDB and hardware steering rules match it correctly. Only the default miss path to the representor fails.
Already ruled out
-
OVS. Removing the representor from ovsbr1 entirely and giving it a plain IP changes nothing.
-
The host and PCIe. The reproducer never touches them.
-
hw-offload. Fails identically with true and with false.
-
ovs-doca vs ovs-kernel. OVS_DOCA=“no”, dpdk_initialized false, no DOCA/DPDK libraries linked, empty datapath_type. The kernel datapath is correct and is what runs.
-
Page size. Originally on the 4K image; reflashed to the 64k default, identical result.
-
Soft state. Reproduces on a fresh install minutes after first boot, and survives a full AC power cycle and an Arm-side openibd restart (representor MACs changed, so the eSwitch genuinely re-initialised).
-
The second eSwitch. 0000:03:00.1 reproduces identically with its own SF pair, so this is not damage to one instance.
-
Firmware knobs. All five INTERNAL_CPU_* values are consistent, with ECPF_ESWITCH_MANAGER and ECPF_PAGE_SUPPLIER both ECPF(1).
-
TC rules and traps. No filters on any interface; every devlink -s trap show counter is zero. No drop, error or discard counter is non-zero anywhere — on the SF, the representor or the uplink.
-
Thermal. Reproduces at 67–69 °C.
-
Version. DOCA 3.4.0 is the current release, and 32.49.1014 is the firmware it ships.
devlink port show reports every port with the expected flavour — pf0hpf as pcipf controller 1 external true, and the SF as pcisf with state active opstate attached.
Questions
-
Is there a known issue in DOCA 3.4.0 or firmware 32.49.1014 where the FDB-miss to representor slow path is not programmed? I found nothing matching in the 3.4.0 known-issues list.
-
Is there a diagnostic that dumps the FDB miss rules directly, so I can confirm whether the slow-path rule exists at all?
-
flow_steering_mode is smfs. I could not test dmfs for comparison — changing it requires the eSwitch in legacy mode, and in DPU mode the host PF vport is permanently attached, so it always reports “E-Switch is busy”, even after deleting the SF. Is there a supported way to switch steering mode on a BlueField-3 in DPU mode?
The uplinks p0 and p1 have no cables fitted and show NO-CARRIER. The reproducer never involves an uplink, but I am flagging it in case the FDB miss path depends on uplink carrier in a way I have not anticipated.
Happy to run any diagnostic on request — the card is on a bench and I can reflash it freely.
Thank you