# VMA 9.8.80: two limits on the current bench explanations

Reviewed 2026-09-10 against vendor tag `9.8.80`, peeled commit
`0dc96e02cd226587c26767fe0350bda3f52f95b2`. SCAN startup logs identify
`9.8.80-1`, built 2026-01-23. This is version-matched upstream source, not proof
that the packaged binary has no downstream patches. No vendor library was changed.

## `VMA_RX_POLL=-1` does not prove an infinite empty TCP read

In [`sockinfo_tcp.cpp`](https://github.com/Mellanox/libvma/blob/0dc96e02cd226587c26767fe0350bda3f52f95b2/src/vma/sock/sockinfo_tcp.cpp),
`rx()` derives blocking mode from the socket and `MSG_DONTWAIT`.
`rx_wait_helper()` polls its receive rings, returns successful completions, then
returns `EAGAIN` for a nonblocking empty result **before** testing the configured
receive-poll count. Only the subsequent blocking branch tests that count or `-1`.
Blocking accept/connect paths therefore need separate analysis.

Our [`libhft/FixSocket.h`](../../engine/cpp/include/libhft/FixSocket.h) uses
`recvmsg(..., MSG_DONTWAIT)` in both receive methods. The older launcher narrative
that this setting makes every empty C++ / Java/JNI / .NET Native TCP receive spin forever
is not supported by this implementation. This does not bound the cost of a CQ
poll, lock contention, or a receive that keeps processing other sockets' traffic.
Keep existing defaults; changing the number is not an established stall fix.

## Four listeners do not prove four active shards

[`ring_slave.cpp`](https://github.com/Mellanox/libvma/blob/0dc96e02cd226587c26767fe0350bda3f52f95b2/src/vma/dev/ring_slave.cpp)
looks up TCP receive-flow objects by endpoint tuple and attaches sinks to an
existing object when the key already exists. Three-tuple listener flows disable
the direct flow-tag shortcut. In
[`rfs.cpp`](https://github.com/Mellanox/libvma/blob/0dc96e02cd226587c26767fe0350bda3f52f95b2/src/vma/dev/rfs.cpp),
new sinks append to the list.
[`rfs_uc.cpp`](https://github.com/Mellanox/libvma/blob/0dc96e02cd226587c26767fe0350bda3f52f95b2/src/vma/dev/rfs_uc.cpp)
visits that list in order and stops when a receiver retains the packet; this
path does not select a listener with a reuse-port tuple hash.

The retained [JNI/VMA shard debug diagnostic](java-jni-vma-shard-debug-diagnostic-20260910.json)
accepted all 32 connections on listener fd 35, despite four correctly pinned
workers. This is consistent with concentrated admission, but it does not prove
which stack/NIC stage caused the subsequent payload stall. Ring20 failed before
Logon; it is not a validated remedy. Before qualifying this cell, record actual
per-listener admission and successful payload service, not just listener counts,
reuse-port flags and worker pins. Do not substitute a pool or different ports and
publish them as the same shard model.