Yang Yang wrote:
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)
I still don't follow: are you running the tx and rx commands sequentially or in parallel? On different (virtual) hosts?
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.
The 26 bytes is a reference to the pattern printed by the test, which iterates over A-Z.
Is your point that each individual segment starts at A, so that a test for pattern {ABC..Z}+ only matches if the segments size is a multiple of 26, else a the pattern will have discontinuities?