Partial #17: raw GPUDirect configs for RTX PRO 6000 Blackwell plus
measured baseline on the dev box. No HDS, RoCE, FFT, or GEMM yet.

Signed-off-by: Chloe Crozier <chloecrozier@gmail.com>

Signed-off-by: Chloe Crozier <chloecrozier@gmail.com>

The RTX PRO configs described a machine with no loopback cable, so the wire
configs pointed at the wrong port pair and the baseline held placeholder
numbers. There is a cable now, and this makes every cell a closed loop over it,
with every rate read from the NIC's own PHY counters.

Harness:

- Resolve the cabled pair from LLDP, or from the wire-loopback namespaces while
  they are up, rather than from enumeration order. This host has a second,
  uncabled ConnectX-7 whose ports also show carrier and look like a pair.
- Fill topology, destination MACs, GPU ordinals and poll cores from discovery,
  and gate every run on pause frames, MTU, the receive-buffer ceiling, and
  frames actually reaching the far port. A run that was flow-controlled or never
  crossed the cable is recorded as a failure, not as a slow result.
- Run RoCE and sockets per role in separate network namespaces, since both ports
  belong to one host and the kernel would otherwise route between them
  internally and never touch the wire.
- Add a container launcher that survives this host's faulted GPU, which makes
  nvidia-container-cli fail NVML enumeration and breaks `docker run --gpus`.

Four ways a run could report something other than what it measured, all fixed:
LD_LIBRARY_PATH searched /opt/daqiri/lib before the build tree, so runs measured
the container image's copy -- which is why ibverbs RX looked broken, the fix
having been in the source and never in the binary under test; the namespace path
dropped --target-gbps, so every drop-curve rung ran flat out under a different
label; a cell that never reached its target drops nothing and so read as the
cleanest point on the curve, hence the NIC's transmit rate is now checked against
the target; and dividing a two-process cell's bytes by its shorter-lived
receiver's window gave 472 Gb/s on a 400 GbE port, hence every rate is now
checked against line rate. "Sustained" was also the highest single one-second
sample, and is now a mean.

Engine: socket_config gains rx_buffer_size / tx_buffer_size, applied at socket
creation and exposed to Python. Without them a UDP receiver gets
net.core.rmem_default -- 256 KB, under four of the 65507 B datagrams this test
sends -- and discards the overflow where no NIC counter and no sender ever sees
it. A kernel clamp is logged, since being silently capped is how a buffer that
looks configured still drops. They have to be configuration rather than a
setsockopt call: a server socket is already receiving during daqiri_init() and a
TCP accepted socket has already inherited the listener's buffers, so both are
sized before an application holds a conn_id. Four docs pages stated the blanket
rule that socket options are never YAML, and now name the exception.

Results are published as docs/benchmarks/performance-rtx-pro-6000.md alongside
the DGX Spark page, and examples/rtx_pro_6000_baseline.md keeps the
host-specific record while deferring every number to that page. RoCE holds
396.9 Gb/s of the 400 GbE port, DPDK GPUDirect 390.5, and socket-udp carries
25 Gb/s without losing a datagram in any repetition.

Signed-off-by: Chloe Crozier <chloecrozier@gmail.com>

Four files carried no weight in this branch and are removed, along with the
code that existed only to serve them:

- scripts/plot_rtx_pro_bench.py: no published figure comes from it, and both
  callers guarded the invocation with a file test, so nothing depended on it.
- examples/run_rtx_pro_push_400g.sh: the exploratory aggregate-throughput
  harness. No measurement on the results page comes from it; the two runners
  that produce every published number are run_rtx_pro_bench.sh and
  run_rtx_pro_mq_bench.sh. Its removal also retires list_loopback_pairs() and
  RTX_LOOPBACK_PAIRS in discovery, which had no other consumer.
- examples/run_rtx_pro_suite.sh: a wrapper around two commands the docs already
  spell out, referenced by nothing.
- examples/daqiri_bench_rdma_tx_rx_rtx_pro_6000.yaml: unreachable. The runner
  selected it only for a software-loopback RoCE run, which the mode guard
  rejects before the config is ever opened. RoCE on this host has to cross a
  namespace or the two ports resolve each other in-kernel and never reach the
  cable, so the netns base is the only config that can serve it.

No behaviour change to any measured path: 893 fewer lines, mkdocs --strict and
check_doc_refs.py clean, and the rdma sw-smoke guard still reports the same
message it did when the dead branch was present.

Signed-off-by: Chloe Crozier <chloecrozier@gmail.com>

Reviewer terminology and structure fixes, with no change to any published
measurement:

- Throughput/goodput replace "sustained on the cable"/"app consumed", and
  "lost packets" replaces "lost on the cable" (cliffburdick).
- The results date is dropped, RoCE is labelled SEND/RECV, and the ibverbs
  section moves ahead of DPDK with the redundant MPRQ qualifier removed.
- An admonition records that each row is that backend's own best case at its
  own transfer size, so RoCE's 8 MB message flatters it against the 8 KB
  packets the raw backends get, and the rows are not a controlled comparison.
- The payload sweep is titled one core per direction and the multi-queue table
  one core per queue, since "2t1r" did not say whether the queues shared a core.
- TCP is described as a single stream rather than a single core, with the
  per-pair DGX Spark figures linked as the reference the review asked about.
- UDP landing below TCP is explained and filed as an engine open item.
- The methodology section now warns that the summary uses the sampled
  per-second mean while the remaining tables use whole-run averages, so
  throughput must not be read across tables.

Harness changes behind those comments:

- issue17 becomes gpu-workload, with the old spelling still accepted so
  existing result directories keep working (RamyaGuru).
- The pacing gate is symmetric: overshooting the target by more than 5% now
  fails a cell the same way undershooting does, since a sender that overshot
  was not holding the rate the row claims.
- buf_size is derived from payload_size for the raw bases, so a payload larger
  than the 8000 B they were written for still fits, and the GPU-workload mode
  selects 8192 B because cuFFT and cuBLAS both pay for a non-power-of-two
  length. The affected table is flagged as predating that change rather than
  restated.
- The wire sampler moves into rtx_pro_nic_counters.sh and the multi-queue
  runner records the sampled rate too, so both runners emit one metric.
- examples/rtx_pro_6000_baseline.md is removed as internal-only (RamyaGuru).

Unrelated to the page, from the same review: apply_socket_int_option now
reports setsockopt failure even when the option is optional, so the guard in
apply_socket_buffer_sizes stops falling through to getsockopt and printing a
"kernel granted" warning after the call failed.

Refreshing the tables themselves, the 8192 B workload cells and the ibverbs
receive-path result are deliberately not in this commit; they need measurements
that are not yet validated.

Signed-off-by: Chloe Crozier <chloecrozier@gmail.com>