From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=eH8LI302; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTP id 353EB5A004E for ; Tue, 22 Oct 2024 15:20:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1729603201; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qO84F0202QFhVDmG4bc5BuLb/inoQY0ht3WF1VBUWOw=; b=eH8LI3023hzzroGFjA4438oZsGqma+segnSB+1wj7IsDRkNhe2ZrxHloDZ+PT4GjSGL44E Bonr4IsqhI9BArP2pSw0f9X0EN7lZ/SYMY6EKZiO2XSaM8TyUlBYU5hN82XQ1si44f3fm2 mcJ+ovTixP5/DjJgu6nChoIy+OjLqFQ= Received: from mail-pl1-f199.google.com (mail-pl1-f199.google.com [209.85.214.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-471-AISMdF8DNzOVzQZlFP6Asg-1; Tue, 22 Oct 2024 09:20:00 -0400 X-MC-Unique: AISMdF8DNzOVzQZlFP6Asg-1 Received: by mail-pl1-f199.google.com with SMTP id d9443c01a7336-20d15285c87so66178855ad.3 for ; Tue, 22 Oct 2024 06:20:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729603199; x=1730207999; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=lMNtmKGJ20ew515lCrLBGY0cEwScUD/ptE0k7nUEWOQ=; b=RWTVUynyfUVxfY/tnQmYYMbzqYsKARZgLeXf4C5rWdEO460nJXgJDwXakkfxbmKfFq fgDHqB0YGaAjD0nDb8aXv9lEY8ehmc+uLDHvlUv/YEFalhmEC0qQZpPjHw4r4OIp1vje 3I9PtplOTtXpe6L+K1dkwchU0rbzmvpUt3JW2pFpl2ACeL1f+AggHKfBpBXRGvj8uYki YnRUTGA2g6kGZqsdy0KIiu0lP81ZP9gxHGcduQVka7qSgiF6LcgW8OQYgOLW/U7vjUYk DVUTikdQmscxzd1JpQR5WSvbHVtD0+biniyCTiqMq7QTzIuOWaihts/4mP6MCEbquPUT gngw== X-Forwarded-Encrypted: i=1; AJvYcCU9BM4uELtFz6aIR74PD16np2KlyTzbWNNoH5+tjw/Yp+ZMDuQ/lL6qBGyzM3pf67FXuYCiSUBSV/8=@passt.top X-Gm-Message-State: AOJu0YwO7BZUTucvi44MEJdttr/BnAmRUtrW1q4FNexj5TKUBtP7Fgbt piZV11L24o+5G1V55BkA1aez5CbgZsudi/lbYi70QMxYRWBkRXeCv2QFYMfn4BzW2QhB+YW2BIV dsya8etEE5XsLmA+t3/WWKwZsFWh/0n/+uYtuL0evR7IkBYIUMasvi4yCjQ== X-Received: by 2002:a17:902:bf49:b0:20c:aae9:7bd7 with SMTP id d9443c01a7336-20e5a9061b2mr154240985ad.39.1729603198711; Tue, 22 Oct 2024 06:19:58 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE1+jqHKGg1by20Mm6Kf4WPeaUS8lkWYUnB+EIlALs3daXkjdHFvPXu/SyEq1C8VQbbfuLLRA== X-Received: by 2002:a17:902:bf49:b0:20c:aae9:7bd7 with SMTP id d9443c01a7336-20e5a9061b2mr154240775ad.39.1729603198331; Tue, 22 Oct 2024 06:19:58 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-20e7f0de4d3sm42786275ad.216.2024.10.22.06.19.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Oct 2024 06:19:57 -0700 (PDT) Date: Tue, 22 Oct 2024 15:19:53 +0200 From: Stefano Brivio To: Laurent Vivier Subject: Re: [PATCH v8 7/8] vhost-user: add vhost-user Message-ID: <20241022151953.3b99a7cd@elisabeth> In-Reply-To: References: <20241010122903.1188992-1-lvivier@redhat.com> <20241010122903.1188992-8-lvivier@redhat.com> <20241015215438.1595b4d7@elisabeth> <20241017021031.1adb421e@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Message-ID-Hash: DXBJIFOGGUX5O5LISABRZ7SCLG64DP5C X-Message-ID-Hash: DXBJIFOGGUX5O5LISABRZ7SCLG64DP5C X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: David Gibson , passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Tue, 22 Oct 2024 14:59:19 +0200 Laurent Vivier wrote: > On 17/10/2024 02:10, Stefano Brivio wrote: > > On Wed, 16 Oct 2024 11:41:34 +1100 > > David Gibson wrote: > > =20 > >> On Tue, Oct 15, 2024 at 09:54:38PM +0200, Stefano Brivio wrote: =20 > >>> [Still partial review] =20 > >> [snip] =20 > >>>> +=09if (peek_offset_cap) > >>>> +=09=09already_sent =3D 0; > >>>> + > >>>> +=09iov_vu[0].iov_base =3D tcp_buf_discard; > >>>> +=09iov_vu[0].iov_len =3D already_sent; =20 > >>> > >>> 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, bu= t > >>> 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 pas= s a > >>> zero iov_len if (peek_offset_cap). =20 > >> =20 > >>> I'll test that (unless you already did) -- if it works, we can fix th= is > >>> up later as well. =20 > >> > >> I believe I tested it at some point, and I think we're already using > >> it somewhere. =20 > >=20 > > 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. > >=20 > > I can reproduce at least one of the two issues consistently (tests > > stopped 5 times out of 5). > >=20 > > 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. > >=20 > > 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(). > > =20 >=20 > I have a fix for that but there is an error I don't understand: > when I run twice the test, the second time I have: >=20 > guest: > # socat -u TCP4-LISTEN:10001 OPEN:test_big.bin,create,trunc > # socat -u TCP4-LISTEN:10001 OPEN:test_big.bin,create,trunc > 2024/10/22 08:51:58 socat[1485] E bind(5, {AF=3D2 0.0.0.0:10001}, 16): Ad= dress already in use >=20 > host: > $ socat -u OPEN:test/big.bin TCP4:127.0.0.1:10001 >=20 > If I wait a little it can work again several times and fails again. >=20 > Any idea? I guess the connection from the first test is not closed properly, so it's still in TIME_WAIT or similar. Given the topic, I can imagine that something goes wrong as we check: if (ack && conn->events & TAP_FIN_SENT && conn->seq_ack_from_tap =3D=3D conn->seq_to_tap) conn_event(c, conn, TAP_FIN_ACKED); in tcp_data_from_tap(). Or something around FIN segments anyway. You can give socat the 'reuseaddr' option, say: socat -u TCP4-LISTEN:10001,reuseaddr OPEN:test_big.bin,create,trunc to see if that's actually the case. > The patch is: >=20 > [...] I can try that in a bit. >From --debug (or --trace) output the issue might be obvious, by the way (you can enable that in the test suite with DEBUG=3D1). I guess you'll see FIN from one side and not from the other one. --=20 Stefano