Why are you running two senders concurrently? The test is not intended to handle that case.
Sorry for the inaccuracy of the description here, these two commands, i.e. with or without GSO, cause the problem. The same goes for patch 2/3. The problem is easily reproducible in the latest kernel, QEMU environment, E1000.
bash# udpgso_bench_tx -l 4 -4 -D "$DST" udpgso_bench_tx: write: Connection refused bash# udpgso_bench_rx -4 -G -S 1472 -v udpgso_bench_rx: data[1472]: len 17664, a(97) != q(113)
bash# udpgso_bench_tx -l 4 -4 -D "$DST" -S 0 udpgso_bench_tx: sendmsg: Connection refused bash# udpgso_bench_rx -4 -G -S 1472 -v udpgso_bench_rx: data[61824]: len 64768, a(97) != w(119)
In one test, the verification data is printed as follows: abcd...xyz ... abcd...xyz abcd...opabcd...xyz
This is because the sender intercepts from the buf at a certain length, which is not aligned according to 26 bytes, and multiple packets are merged. The verification of the receiving end needs to be performed after splitting.