Re: [PATCH v8 7/8] vhost-user: add vhost-user

On Wed, 16 Oct 2024 11:41:34 +1100
David Gibson <david(a)gibson.dropbear.id.au> wrote:

...
  On Tue, Oct 15, 2024 at 09:54:38PM +0200, Stefano
Brivio wrote:
  [Still partial review]   
 [snip]
 
  +	if
(peek_offset_cap)
 +		already_sent = 0;
 +
 +	iov_vu[0].iov_base = tcp_buf_discard;
 +	iov_vu[0].iov_len = already_sent;   
 
 I think I had a similar comment to a previous revision. Now, I haven't
 tested this (yet) on a kernel with support for SO_PEEK_OFF on TCP, but
 I think this should eventually follow the same logic as the (updated)
 tcp_buf_data_from_sock(): we should use tcp_buf_discard only if
 (!peek_offset_cap).
 
 It's fine to always initialise VIRTQUEUE_MAX_SIZE iov_vu items,
 starting from 1, for simplicity. But I'm not sure if it's safe to pass a
 zero iov_len if (peek_offset_cap).   
 
  I'll test that (unless you already did) --
if it works, we can fix this
 up later as well.   
 
 I believe I tested it at some point, and I think we're already using
 it somewhere. 
I tested it again just to be sure on a recent net.git kernel: sometimes
the first test in passt_vu_in_ns/tcp, "TCP/IPv4: host to guest: big
transfer" hangs on my setup, sometimes it's the "TCP/IPv4: ns to guest
(using loopback address): big transfer" test instead.

I can reproduce at least one of the two issues consistently (tests
stopped 5 times out of 5).

The socat client completes the transfer, the server is still waiting
for something. I haven't taken captures yet or tried to re-send from
the client.

It all works (consistently) with an older kernel without support for
SO_PEEK_OFF on TCP, but also on this kernel if I force peek_offset_cap
to false in tcp_init().

-- 
Stefano