Re: [PATCH v3 0/2] tcp: unify IPv4 and IPv6 tap queues

On 2024-09-24 16:30, Stefano Brivio wrote:
...
  On Thu, 19 Sep 2024 14:44:07 -0400
 Jon Maloy <jmaloy(a)redhat.com> 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