public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: passt-dev@passt.top, Stefano Brivio <sbrivio@redhat.com>
Cc: David Gibson <david@gibson.dropbear.id.au>
Subject: [PATCH v4 4/8] udp: Don't handle tap receive batch size calculation within a #define
Date: Thu,  5 Jan 2023 15:26:21 +1100	[thread overview]
Message-ID: <20230105042625.1981812-5-david@gibson.dropbear.id.au> (raw)
In-Reply-To: <20230105042625.1981812-1-david@gibson.dropbear.id.au>

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 <david@gibson.dropbear.id.au>
---
 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;
 
-- 
@@ -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


  parent reply	other threads:[~2023-01-05  4:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-05  4:26 [PATCH v4 0/8] Don't use additional sockets for receiving "spliced" UDP communications David Gibson
2023-01-05  4:26 ` [PATCH v4 1/8] udp: Move sending pasta tap frames to the end of udp_sock_handler() David Gibson
2023-01-05  4:26 ` [PATCH v4 2/8] udp: Split sending to passt tap interface into separate function David Gibson
2023-01-05  4:26 ` [PATCH v4 3/8] udp: Split receive from preparation and send in udp_sock_handler() David Gibson
2023-01-05  4:26 ` David Gibson [this message]
2023-01-05  4:26 ` [PATCH v4 5/8] udp: Pre-populate msg_names with local address David Gibson
2023-01-05  4:26 ` [PATCH v4 6/8] udp: Unify udp_sock_handler_splice() with udp_sock_handler() David Gibson
2023-01-05  4:26 ` [PATCH v4 7/8] udp: Decide whether to "splice" per datagram rather than per socket David Gibson
2023-01-05  4:26 ` [PATCH v4 8/8] udp: Don't use separate sockets to listen for spliced packets David Gibson
2023-01-05 21:50 ` [PATCH v4 0/8] Don't use additional sockets for receiving "spliced" UDP communications Stefano Brivio
2023-01-06  0:59   ` David Gibson
2023-01-13  0:07   ` Stefano Brivio

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230105042625.1981812-5-david@gibson.dropbear.id.au \
    --to=david@gibson.dropbear.id.au \
    --cc=passt-dev@passt.top \
    --cc=sbrivio@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://passt.top/passt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).