Default data QPs to infinite RNR retries

[davidcanar]

Problem

A SEND that arrives before the peer has posted its receive gets an RNR NAK. With the verbs defaults (rnr_retry = 0, retry_cnt = 0) the module completes that SEND immediately with RNR_RETRY_EXC_ERR and then marks the QP in error, taking the whole connection down on a single scheduler-induced race between the sender's post_send and the receiver's post_recv.

This bit us while running ds4's two-machine tensor parallelism over usb4_rdma0: the gate protocol posts receives and sends in lockstep from two machines, and a microseconds-scale race at the first decode gate (or at a bulk round boundary) errored the QP permanently. The only robust workaround on the userspace side was a two-QP design with receives always posted before any send could arrive — but the race is inherent to two-sided UC/RC usage and any application can hit it.

Change

In tbv_create_qp, default non-GSI QPs to infinite RNR retries (rnr_retry = 7, per the IB spec) and a retry count. A SEND that hits an RNR then waits for the peer's advertised recv credits (tbv_send_rnr_waits_for_recv_credit) instead of completing with an error. Applications can still override both through modify_qp (IB_QP_RNR_RETRY / IB_QP_RETRY_CNT).

Testing

• Built via DKMS for 7.1.8-200.fc44 and loaded on both machines of a Thunderbolt pair.
• uc_oneway --role bidi --check: 64/64 both directions, pattern checks pass.
• ds4 tensor parallelism over usb4_rdma0: 4 concurrent sessions, 445-token prefills, multi-turn sessions, ~14 tok/s decode — zero QP errors (the previous default killed the QP on the first race).