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

[Jon Maloy <jmaloy@redhat.com>]

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