Mellanox ConnectX-4 EN 100GbE network card

TrueNAS General
22

Note, Pfsense runs on BSD, not Debian.

Just came across this thread as I am looking for options for my home network and some changes.

23

Well, my annoyance has dissipated, so I am going to be working directly with the debian codebase. If nobody else will fix it, I will.

Root Cause: nic_receive_steering_discard in mlx5_core

This is a specific, well-defined failure in the mlx5_core driver’s flow steering initialization, not a vague compatibility problem. Here’s what the code actually tells us:

What the counter means in the source

In drivers/net/ethernet/mellanox/mlx5/core/en_stats.c, rx_steer_missed_packets maps directly to vport_env.nic_receive_steering_discard GitHub — a hardware register queried from the NIC’s VNIC environment. This counter increments when a packet arrives at the physical port but the NIC’s internal hardware flow table has no matching rule directing it to any receive queue (RQ). The hardware’s default miss action is drop. The fact that rx_packets_phy and rx_steer_missed_packets are moving in perfect lockstep at a rate of 1:1 tells you unambiguously that zero valid steering entries exist — the entire steering table is empty or broken from the driver’s perspective.

How it’s supposed to work

During mlx5_core probe, the driver sets up a chain of flow tables. Packets received on the uplink port are matched against entries in the NIC’s hardware steering table (the Flow Steering layer), which routes them to specific RQs. The key path is:

mlx5e_open_channels() → mlx5e_activate_priv_channels() → flow table programming via mlx5e_arfs_* / mlx5e_fs_* functions.

If any step in that chain fails silently, the hardware is left with an empty table, and every packet hits the miss/drop path — producing exactly the symptom described.

Why kernel 6.12 vs 6.14 matters

The bug report’s clearest data point is the controlled comparison: same card, same cable, same switch, same firmware — Proxmox on kernel 6.14.8 works, TrueNAS on kernel 6.12.15 does not. There were several significant mlx5 flow steering refactors that landed between 6.12 and 6.14. The three most likely culprits based on the failure mode:

  1. Changes to how the default NIC receive table is initialized for OEM cards. OEM cards with non-standard PSIDs (this card is MT_2150110033, an OEM variant) may hit different capability code paths. If a capability check returns false unexpectedly, the steering table setup is skipped silently.

  2. The smfs (software-managed flow steering) path being broken or missing. The report confirms that attempting flow_steering_mode smfs fails with “not supported.” In kernel 6.12, dmfs (device-managed flow steering) is the default. Attempting to switch to smfs results in the error “Software managed steering is not supported by current device,” TrueNAS Community which means the fallback path for when dmfs fails is also blocked.

  3. CONFIG_MLX5_CLS_ACT not being compiled in. Attempts to manually program a hardware steering rule via tc filter add... skip_sw result in “Operation not supported,” and when u32 skip_sw is tried, the rule is accepted but tc -s filter show reveals it is not_in_hw TrueNAS Community — meaning the kernel is built without the necessary TC action offload support that would let a user manually work around the broken steering table.

Why this is a regression, not a hardware issue

The evidence is solid: the exact same hardware configuration (card, transceiver, cable, switch) functions perfectly in a Proxmox environment running a newer kernel (6.14.8-2-pve) TrueNAS Community. The driver initializes cleanly with no errors in dmesg, link comes up at 40Gb/s correctly — it’s purely the flow table programming that fails silently.

The earlier EEPROM bug (different issue, same driver)

For completeness, there’s an older and separate mlx5 bug in port.c that’s sometimes conflated with this: when querying the module EEPROM, there was a misusage of the offset variable vs the query.offset field Linux-Kernel Archive, introduced in kernel 5.13 by a refactoring commit and fixed between 5.15.12 and 5.15.25. That bug caused bit errors and broken ethtool EEPROM reads, not 100% packet drop - and it’s long since fixed in any 6.x kernel.