Is this just similar or the actual thing?
Sixunited AXB35 uses Strix Halo USB4 Host Router (documented as two 40Gbps USB4) with what looks like Parade PS8830 retimer chips. The product sheet for that mentions 40Gbps x 2 lanes, but I think it actually means 4 pairs of 20Gbps each, of which 2 have switchable direction. Being part of the SoC the controller could well be faster than PCIe 4x4; host to host also doesn’t use PCIe tunneling mode.
Similar in that it’s for the same hardware. It’s not an RDMA driver, it’s individual streams (with software copying).
I’m guessing you mean the USB4NET frame limit. USB4 frames are 4K and the descriptors simply have no bits for larger sizes. USB4NET adds 12 bytes per USB4 frame, plus an Ethernet overhead of 18 bytes (including type and CRC), and an arbitrary 64K limit, which probably means the optimal MTU there is something like 65326 for 16 4K frames. The USB4NET frame counters are 16 bit and size 32 bit so the protocol could be extended for near 256M frames.
The overhead here comes from software calculating the Ethernet CRC32 and fragmenting into 4K frames, each with a 12 byte header and its own transfer descriptor. The USB4STREAM protocol avoids the CRC and fragment headers. Side note: The CRC32 can be computed in parallel, so we could imagine offloading the entire fragmentation and checksumming pass to GPU or NPU. Given the RS-FEC in USB4, we probably don’t need the CRC for anything but USB4NET’s Ethernet compatibility.
As for actual RDMA, the hardware has a few limits. Buffers support an offset, but writes are in 32bit words. One could in principle split transfers (using HopID) into control queues (with entire transfer descriptors) and data queues, but that may still require the target processor to wake up to submit the control queue changes to the host controller (using the producer&consumer indexes register). This would probably not perform very well due to round trips being required for the flow control of the data, but I haven’t tested the idea.