From mboxrd@z Thu Jan 1 00:00:00 1970 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 246B25A005E for ; Wed, 4 Jan 2023 18:45:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1672854330; 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=RGgVJFz/Am6rBUe/T+KGYHudvS9RTAO9kLHun5wkFrc=; b=iS9uIHpA/jWVpdm5ihQcEsSfBAnxGDPQLY6pNPtwKdIgrZVNtz5fEpm8R77/UPydPndfKZ VdBfKa1BabqwcRZkAXzpg8YYhSyWVp2SjYGfgQUY5WKV/0T8lpEIhuGIW3bc347ee2sWhC 1YH/FKlNZM4b0EIOHt9ae1b7K1v+DkQ= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-47-kXCyVr8TMI6k01AhaDAfpg-1; Wed, 04 Jan 2023 12:45:28 -0500 X-MC-Unique: kXCyVr8TMI6k01AhaDAfpg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 96A711C0A586; Wed, 4 Jan 2023 17:45:28 +0000 (UTC) Received: from maya.cloud.tilaa.com (ovpn-208-4.brq.redhat.com [10.40.208.4]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5DD1851E5; Wed, 4 Jan 2023 17:45:28 +0000 (UTC) Date: Wed, 4 Jan 2023 18:45:25 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v2 17/18] udp: Use tap_send_frames() Message-ID: <20230104184525.31fc2f87@elisabeth> In-Reply-To: <20221209054228.4085990-18-david@gibson.dropbear.id.au> References: <20221209054228.4085990-1-david@gibson.dropbear.id.au> <20221209054228.4085990-18-david@gibson.dropbear.id.au> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: KPEQZAJ2YTENQPURIUBAC4C4PEYWMABL X-Message-ID-Hash: KPEQZAJ2YTENQPURIUBAC4C4PEYWMABL 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: passt-dev@passt.top X-Mailman-Version: 3.3.3 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 Fri, 9 Dec 2022 16:42:27 +1100 David Gibson wrote: > To send frames on the tap interface, the UDP uses a fairly complicated two > level batching. First multiple frames are gathered into a single "message" > for the qemu stream socket, then multiple messages are send with > sendmmsg(). We now have tap_send_frames() which already deals with sending > a number of frames, including batching and handling partial sends. Use > that to considerably simplify things. > > This does make a couple of behavioural changes: > * We no longer split messages to keep them under 64kiB, which comments > say is necessary. However the TCP code didn't have equivalent code, so > either this isn't actually needed, or we should implement for both > (which is now easier since it can be done in one place). That used to be SHRT_MAX (32 KiB - 1), not 64 KiB. For some reason, if I sent messages with multiple frames, with any one of them larger than 32 KiB, qemu used to close the connection. But it looks like this was caused by some issue in the handling of short sends rather than an issue in qemu, especially given that, with this series applied, I don't hit the original issue (and I could predictably reproduce it earlier). -- Stefano