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 7C0135A005E for ; Thu, 17 Nov 2022 08:21:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668669686; 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=+p+vDBnufSYRYisJndOVZiVy4BhitKidA+i232IWO1g=; b=FaJcpauedByRBTerbHXgnbZ2QwCxI7aDkbmS8OWrwlc/z93QpSoBCi2i6ChkWDHBOW3L+U lunX2DIQIRv3Wk6YYk0rf9VxbGZJCaGJeGmdPH02FAcq8rEz0Vr08wGRue1HOfAKVOYt/a IZq4yEnBhWEMTpUjWpMmgQxXLserCu0= 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-395-0VJ46JxoMMqZYq0ixjnIvQ-1; Thu, 17 Nov 2022 02:21:24 -0500 X-MC-Unique: 0VJ46JxoMMqZYq0ixjnIvQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 5AC941C0519E; Thu, 17 Nov 2022 07:21:24 +0000 (UTC) Received: from maya.cloud.tilaa.com (ovpn-208-8.brq.redhat.com [10.40.208.8]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 016BE2024CC8; Thu, 17 Nov 2022 07:21:23 +0000 (UTC) Date: Thu, 17 Nov 2022 08:21:00 +0100 From: Stefano Brivio To: David Gibson Subject: Re: UDP "splicing" fairly broken :( Message-ID: <20221117082100.5fb5ee2d@elisabeth> In-Reply-To: References: Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: UZE2E64RGCYC4MLPM4HT67NYZMIJOZUK X-Message-ID-Hash: UZE2E64RGCYC4MLPM4HT67NYZMIJOZUK 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 Thu, 17 Nov 2022 16:07:32 +1100 David Gibson wrote: > In preparation for trying to implement dual stack sockets for UDP, > I've been getting my head around how the UDP splicing works. Alas, > I'm pretty sure that it's broken if there's not a one-to-one > correspondence between init side source ports and ns side destination > ports. That will typically be the case, but given its UDP there's no > guarantee. I understand the concern below, but I don't understand this part, that is: in which other way is it broken? > In addition, UDP servers in the ns will not see the correct port > numbers with getpeername(). That's also true of spliced TCP > connections (see https://bugs.passt.top/show_bug.cgi?id=39), but it's > more likely to matter for UDP (I don't know of any TCP protocols that > care about source port number on the server side, but there are some > common UDP protocols that have at least port number conventions on > both sides). I can think of DHCP and DNS, for which we offer special handling somehow. Still, if the flow is started by the guest or container, replies should really come with a source port matching the destination port used initially. For TCP, I don't see this is as an issue at all. > I can expand on the details later, but pasta will do the wrong thing > in at least some circumstances for both a single init side socket > sendto()ing packets to multiple different ports in the ns/guest and > multiple init side sockets send()ing to the same port in the ns/guest. > > I think I know how to fix it, but it's not a trivial job. So, the > question is do I embark on this now, or do I just remove UDP > "splicing" entirely for the time being (other than a minimum required > to make -U work)? That would unblock dual stack UDP sockets and we > can attempt to reoptimize this later. So, I'm not really sure what's broken here, but in any case, UDP "splicing" doesn't offer as much value as the TCP one does, the difference in packet rate is not that big. I don't see a problem if we want to remove it temporarily. The only real concern I have is how easy it would be to add it back after a rework not taking that functionality into account. -- Stefano