Re: [PATCH v7 00/31] Introduce discontiguous frames management

[Laurent Vivier <lvivier@redhat.com>]

On 18/07/2025 20:45, Stefano Brivio wrote:
> On Mon, 23 Jun 2025 13:06:04 +0200
> Laurent Vivier <lvivier@redhat.com> wrote:
> 
>> This series introduces iov_tail to convey frame information
>> between functions.
>>
>> This is only an API change, for the moment the memory pool
>> is only able to store contiguous buffer, so, except for
>> vhost-user in a special case, we only play with iovec array
>> with only one entry.
>>
>> v7:
>>      - Add a patch to fix comment style of 'Return:'
>>      - Fix ignore_arp()/accept_arp()
>>      - Fix coverity error
>>      - Fix several comments
> 
> I was about to apply this without 1/31 (I applied the v2 of it you sent
> outside of this series instead, which is actually up to date) and with
> the minor comment fix to 31/31... but the test perf/passt_vu_tcp fails
> rather consistently now (and I triple checked without this series):
> 
> - "TCP throughput over IPv6: guest to host" with MTU 1500 and 9000
>    bytes now reports between 0 and 0.6 Gbps. The guest kernel prints a
>    series of two messages with ~1-10 µs interval:
> 
> [   21.159827] TCP: out of memory -- consider tuning tcp_mem
> [   21.159831] TCP: out of memory -- consider tuning tcp_mem
> 
> - "TCP throughput over IPv4: guest to host" never reports 0 Gbps, but
>    the throughput figure for large MTU (65520 bytes) is very low (5.4
>    Gbps in the last run). Here I'm getting four messages:
> 
> [   40.807818] TCP: out of memory -- consider tuning tcp_mem
> [   40.807829] TCP: out of memory -- consider tuning tcp_mem
> [   40.807829] TCP: out of memory -- consider tuning tcp_mem
> [   40.807830] TCP: out of memory -- consider tuning tcp_mem
> 
> - on the reverse direction, "TCP throughput over IPv4: host to guest"
>    (but not with IPv6), the iperf3 client gets SIGSEGV, but not
>    consistently, it happened once out of five times.
> 
> To me it smells a bit like we're leaking virtqueue slots but I looked
> again at the whole series and I couldn't find anything obvious... at
> least not yet.
> 
> UDP tests never fail and the throughput is the same as before.
> 

I think the problem is the way we use the iovec array.

In tap4_handler() we have a packet_get() that provides a pointer to the iovec array from 
pool. Idx is 0, iovec idx is 0.

Then we have a pool_flush(), so first available idx is now 0 again.

And then we have packet_add() with the iovec idx (in "data") of the previous packet_get() 
that we try to add at the same index (as pool is empty again, and first available idx is 0).

When I wrote this patch I guessed that when we release packet (pool_flush()) we don't use 
anymore the iovec array of the packet, it appears to be not true.

Thanks,
Laurent