From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id E29785A0277 for ; Wed, 30 Nov 2022 05:13:28 +0100 (CET) Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4NMQmZ55zvz4xYV; Wed, 30 Nov 2022 15:13:18 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=201602; t=1669781598; bh=YO4ouhxeEzW8I6Zdf9Wq5KGSE/BwtYB/UUCIXcSdelY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Gqr4m0imU67Obr/SiW8JJ9JXjtL51GrISoQwL94h9jGIRNnOd5atszkZDlz1Yx8au kyPe3trzYksop2KEmuFba2KjfAadxpey11doP6838/n281aQGbZ0co4eH+OBtcZ9rH IoNvsxNeRqZ/av1aVktVz8zDQ+f4flSTA+tbJsyE= From: David Gibson To: Stefano Brivio , passt-dev@passt.top Subject: [PATCH v4 16/16] udp: Correct splice forwarding when receiving from multiple sources Date: Wed, 30 Nov 2022 15:13:16 +1100 Message-Id: <20221130041316.2539575-17-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221130041316.2539575-1-david@gibson.dropbear.id.au> References: <20221130041316.2539575-1-david@gibson.dropbear.id.au> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID-Hash: RC4V2RPLUSLWCBWQBB2UAYRYWGLW63ZP X-Message-ID-Hash: RC4V2RPLUSLWCBWQBB2UAYRYWGLW63ZP X-MailFrom: dgibson@gandalf.ozlabs.org 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 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: udp_sock_handler_splice() reads a whole batch of datagrams at once with recvmmsg(). It then forwards them all via a single socket on the other side, based on the source port. However, it's entirely possible that the datagrams in the set have different source ports, and thus ought to be forwarded via different sockets on the destination side. In fact this situation arises with the iperf -P4 throughput tests in our own test suite. AFAICT we only get away with this because iperf3 is strictly one way and doesn't send reply packets which would be misdirected because of the incorrect source ports. Alter udp_sock_handler_splice() to split the packets it receives into batches with the same source address and send each batch with a separate sendmmsg(). For now we only look for already contiguous batches, which means that if there are multiple active flows interleaved this is likely to degenerate to batches of size 1. For now this is the simplest way to correct the behaviour and we can try to optimize later. Signed-off-by: David Gibson --- udp.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/udp.c b/udp.c index efd3013..598c793 100644 --- a/udp.c +++ b/udp.c @@ -584,8 +584,8 @@ static void udp_splice_sendfrom(const struct ctx *c, unsigned start, unsigned n, static void udp_sock_handler_splice(const struct ctx *c, union epoll_ref ref, uint32_t events, const struct timespec *now) { - in_port_t src, dst = ref.r.p.udp.udp.port; - int v6 = ref.r.p.udp.udp.v6, n; + in_port_t dst = ref.r.p.udp.udp.port; + int v6 = ref.r.p.udp.udp.v6, n, i, m; struct mmsghdr *mmh_recv; if (!(events & EPOLLIN)) @@ -619,9 +619,18 @@ static void udp_sock_handler_splice(const struct ctx *c, union epoll_ref ref, }); } - src = sa_port(v6, mmh_recv[0].msg_hdr.msg_name); - udp_splice_sendfrom(c, 0, n, src, dst, v6, - ref.r.p.udp.udp.ns, ref.r.p.udp.udp.orig, now); + for (i = 0; i < n; i += m) { + in_port_t src = sa_port(v6, mmh_recv[i].msg_hdr.msg_name); + + for (m = 1; i + m < n; m++) { + void *mname = mmh_recv[i + m].msg_hdr.msg_name; + if (sa_port(v6, mname) != src) + break; + } + + udp_splice_sendfrom(c, i, m, src, dst, v6, ref.r.p.udp.udp.ns, + ref.r.p.udp.udp.orig, now); + } } /** -- 2.38.1