BlueField CQE Vender Syndrome Code 0x9f During Flow Hash Table Update

Infrastructure & Networking BlueField
1

Hi,

During updating flow hash table through WQE, I’ve encountered a CQE Error whose syndrome and vendor_err_synd are

syndrome: 0x2
vendor_err_synd: 0x9f

Could you please provide the meaning and recommended actions for this error?

2

Hi Pusnow1

We’ll probably need a bit more context before we can narrow down the issue.

Could you please share a few more details?

  • The full error message / log line that includes this CQE error (with the syndrome, vendor_err_synd)

  • The exact DOCA / SDK version you’re using

  • BlueField NIC firmware version (output of mlxfwmanager -d <dev> q or flint -d <dev> q)

  • Which DOCA sample or application was running, and roughly what operation it was doing when the error occurred

Thanks

Xu

3

Hi Xu,

  1. I’m currently directly issuing commands through DevX with PRM. so I only got CQE Error

syndrome: 0x2
vendor_err_synd: 0x9f

  1. upstream rdma-core library, but I’m only using DevX APIS (e.g., mlx5dv_devx_obj_create)

Device Type: BlueField3
Part Number: 900-9D3B6-00CV-A_Ax
Description: NVIDIA BlueField-3 B3220 P-Series FHHL DPU; 200GbE (default mode) / NDR200 IB; Dual-port QSFP112; PCIe Gen5.0 x16 with x16 PCIe extension option; 16 Arm cores; 32GB on-board DDR; integrated BMC; Crypto Enabled
PSID: MT_0000000884
PCI Device Name: mlx5_2
Base MAC: XXX
Versions: Current Available
FW 32.43.1014 N/A
PXE 3.7.0500 N/A
UEFI 14.36.0016 N/A
UEFI Virtio blk 22.4.0014 N/A
UEFI Virtio net 21.4.0013 N/A

Status: No matching image found

  1. No RDMA-Core / Doca / DPDK sample application covers my use cases
    1. Flow Hash Table in RDMA-Core directly accesses ICM, not documented in PRM I have
    2. Flow Hash Table in DPDK uses GTA WQE not documented in PRM I have
    3. The Only Documented Flow Hash Table WQE in PRM I have is FlowUpdate WQE.

Thanks,

Wonsup

4

Hi Wonsup,

Thanks for the update.

Short answer on the CQE:

  • syndrome = 0x2 is a Local QP Operation Error – the HCA is unhappy with the WQE or local resources (QP/context/memory), not with the remote side or the wire.

  • vendor_err_synd = 0x9f is a device‑specific extension code. It isn’t decoded in the PRM version you have. Internally, this kind of combo (0x2 + a vendor code) usually shows up when the operation or resources are considered invalid or unsupported – e.g. WQE format not what the HCA expects, a feature/capability not enabled, or an access that doesn’t line up with the configured memory / ICM layout.

In your setup, you are:

  • Using upstream rdma-core, but only the DevX APIs (e.g. mlx5dv_devx_obj_create), and

  • Implementing flow hash table updates directly based on PRM, while noting that:

    Flow Hash Table in RDMA-Core directly accesses ICM, not documented in PRM I have

Flow Hash Table in DPDK uses GTA WQE not documented in PRM I have

The Only Documented Flow Hash Table WQE in PRM I have is FlowUpdate WQE.

Given this, the most likely interpretation is:

  • The CQE error is not indicating a generic link/transport issue, but rather that the specific WQE / flow‑hash‑table update path you are using is outside the set of documented and supported interfaces in your PRM revision, so the device rejects the operation and reports a local‑operation error with a vendor‑specific syndrome.

Practically, I may suggest you:

  • Limit your DevX usage for flow programming to documented WQE types and commands in the PRM you have (e.g. the documented FlowUpdate WQE), or to higher‑level APIs in DOCA / DPDK / rdma-core that are explicitly supported for flow programming.

  • Avoid relying on:

    • Direct ICM access patterns copied from rdma-core

    • Undocumented GTA WQE formats taken from DPDK sources, as those are not guaranteed to be compatible with your current FW/PSID/PRM combination and can legitimately trigger local operation errors like the one you are seeing.

With the current undocumented path, there is no official programming model we can rely on to give a precise “do X to fix 0x9f” instruction.

Regards

Xu

5

Hi Xu,

Thank you for your kind answer and suggestions!

I will stick into rdma-core’s higer level APIs.

Thanks,

Wonsup