From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gandalf.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id C92715A005E for ; Wed, 4 Jan 2023 06:44:36 +0100 (CET) Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4Nmz7d3BMcz4y0k; Wed, 4 Jan 2023 16:44:29 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=201602; t=1672811069; bh=XROyn2xEsrbGiaazn31rGUHhEuoi6nLIdELpXOyEWT4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TPmZ0NMJ7z6//A+71jDSBbPkGw6W7r5WUNfElHz3KXKPR7zopvr05aTe/rag9aSk/ CLGD+CGjuLrnnP3tEvXD3ZI1RViQDi+7UersegPkpRVRnb8gcLa39WIjz/mWvSwZBW b1HZdMs5J+GtLgQxzMHKWD9x2MRBQup5HHxEVB1o= From: David Gibson To: passt-dev@passt.top, Stefano Brivio Subject: [PATCH v3 4/8] udp: Don't handle tap receive batch size calculation within a #define Date: Wed, 4 Jan 2023 16:44:22 +1100 Message-Id: <20230104054426.120668-5-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.39.0 In-Reply-To: <20230104054426.120668-1-david@gibson.dropbear.id.au> References: <20230104054426.120668-1-david@gibson.dropbear.id.au> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID-Hash: DVWHO7BI7F6TBAW4KCP4G7UQ2Q5CNEZF X-Message-ID-Hash: DVWHO7BI7F6TBAW4KCP4G7UQ2Q5CNEZF 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_MAX_FRAMES gives the maximum number of datagrams we'll ever handle as a batch for sizing our buffers and control structures. The subtly different UDP_TAP_FRAMES gives the maximum number of datagrams we'll actually try to receive at once for tap packets in the current configuration. This depends on the mode, meaning that the macro has a non-obvious dependency on the usual 'c' context variable being available. We only use it in one place, so it makes more sense to open code this. Add an explanatory comment while we're there. Signed-off-by: David Gibson --- udp.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/udp.c b/udp.c index 64c9219..6951c4c 100644 --- a/udp.c +++ b/udp.c @@ -119,7 +119,6 @@ #define UDP_CONN_TIMEOUT 180 /* s, timeout for ephemeral or local bind */ #define UDP_MAX_FRAMES 32 /* max # of frames to receive at once */ -#define UDP_TAP_FRAMES (c->mode == MODE_PASST ? UDP_MAX_FRAMES : 1) /** * struct udp_tap_port - Port tracking based on tap-facing source port @@ -950,10 +949,14 @@ static void udp_tap_send(const struct ctx *c, void udp_sock_handler(const struct ctx *c, union epoll_ref ref, uint32_t events, const struct timespec *now) { + /* For not entirely clear reasons (data locality?) pasta gets + * better throughput if we receive the datagrams one at a + * time. + */ + ssize_t n = (c->mode == MODE_PASST ? UDP_MAX_FRAMES : 1); in_port_t dstport = ref.r.p.udp.udp.port; bool v6 = ref.r.p.udp.udp.v6; struct mmsghdr *sock_mmh; - ssize_t n; if (events == EPOLLERR) return; @@ -968,7 +971,7 @@ void udp_sock_handler(const struct ctx *c, union epoll_ref ref, uint32_t events, else sock_mmh = udp4_l2_mh_sock; - n = recvmmsg(ref.r.s, sock_mmh, UDP_TAP_FRAMES, 0, NULL); + n = recvmmsg(ref.r.s, sock_mmh, n, 0, NULL); if (n <= 0) return; -- 2.39.0