This is not likely to be a realistic problem for a while, just something noticed while reading, but in the interest of recording observations... Sockets have only finite buffers associated with them, so when doRFVIDII uses mapM_ over the sequence of DII packets to send the tests to the DUTs without reading from the corresponding RVFI streams, it's relying on being able to fit the entire test (and its RVFI replies) in socket buffers. Granted, the smallest test that will encounter this problem is one that overflows the sum of all four of QCVE's rcvbuf (holding processed RVFI messages), the DUT's sndbuf (ditto), the DUT's rcvbuf (holding DII packets), and QCVE's sndbuf (ditt), so that's probably rather sizable, but perhaps there's a concise way to rewrite trace evaluation as a fold of combined send-and-recvs (or as a pair of threads each folding, one doing the send and one doing the recvs, to still get the latency hiding benefits).
This is not likely to be a realistic problem for a while, just something noticed while reading, but in the interest of recording observations... Sockets have only finite buffers associated with them, so when
doRFVIDIIusesmapM_over the sequence of DII packets to send the tests to the DUTs without reading from the corresponding RVFI streams, it's relying on being able to fit the entire test (and its RVFI replies) in socket buffers. Granted, the smallest test that will encounter this problem is one that overflows the sum of all four of QCVE's rcvbuf (holding processed RVFI messages), the DUT's sndbuf (ditto), the DUT's rcvbuf (holding DII packets), and QCVE's sndbuf (ditt), so that's probably rather sizable, but perhaps there's a concise way to rewrite trace evaluation as a fold of combined send-and-recvs (or as a pair of threads each folding, one doing the send and one doing the recvs, to still get the latency hiding benefits).