On 2024-09-24 16:30, Stefano Brivio wrote:
On Thu, 19 Sep 2024 14:44:07 -0400 Jon Maloy
wrote: This should save us some memory and code.
--- v2: - Setting pointers to pre-set IP and MAC headers on the fly instead of copying them. - Merged patch #2 and #3 from v1 v3: - Changes based on feedback from team Sorry for the delay, now tests go a bit further but I have a similar problem as I had on v2: guest to host, IPv6, with 65520 bytes MTU only (perf/passt_tcp case), the iperf3 server fails to receive results, test suite output:
=== perf/passt_tcp
passt: throughput and latency Throughput in Gbps, latency in µs, 4 threads at 3.6 GHz MTU: | 256B | 576B | 1280B | 1500B | 9000B | 65520B | |--------|--------|--------|--------|--------|--------| TCP throughput over IPv6: guest to host | - | - | 5.8 | 6.5 | 18.1 |
and matching iperf3 server output:
- - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 6] 0.00-1.01 sec 568 MBytes 4.74 Gbits/sec receiver [ 9] 0.00-1.01 sec 621 MBytes 5.18 Gbits/sec receiver [ 11] 0.00-1.01 sec 569 MBytes 4.75 Gbits/sec receiver [ 13] 0.00-1.01 sec 675 MBytes 5.63 Gbits/sec receiver [SUM] 0.00-1.01 sec 2.38 GBytes 20.3 Gbits/sec receiver iperf3: error - unable to receive results: Bad file descriptor
after that, connectivity from the guest seems to be pretty much gone. I didn't debug further.
Thanks, I'll look into this. That aside, I ran a performance test with my latest patch, and it turns out that performance pasta->host was significantly degraded after the patch was applied. When increasing the frame array to 256 it was better, but still not back to the original performance. I have a strong suspicion this is related to the kernel bug I still haven't re-posted, so I will give that one a try. ///jon