aboutgitcodebugslistschat
diff options
context:
space:
mode:
authorDavid Gibson <david@gibson.dropbear.id.au>2025-04-04 21:15:35 +1100
committerStefano Brivio <sbrivio@redhat.com>2025-04-07 21:31:54 +0200
commit5221e177e132b8b5001ec97f42975ad1251f7110 (patch)
tree7000d6576199e54955defbd52ba9863193077905
parent3a0881dfd02d758b0dc8ca6f5732bcb666b6d21e (diff)
downloadpasst-5221e177e132b8b5001ec97f42975ad1251f7110.tar
passt-5221e177e132b8b5001ec97f42975ad1251f7110.tar.gz
passt-5221e177e132b8b5001ec97f42975ad1251f7110.tar.bz2
passt-5221e177e132b8b5001ec97f42975ad1251f7110.tar.lz
passt-5221e177e132b8b5001ec97f42975ad1251f7110.tar.xz
passt-5221e177e132b8b5001ec97f42975ad1251f7110.tar.zst
passt-5221e177e132b8b5001ec97f42975ad1251f7110.zip
udp: Parameterize number of datagrams handled by udp_*_reply_sock_data()
Both udp_buf_reply_sock_data() and udp_vu_reply_sock_data() internally decide what the maximum number of datagrams they will forward is. We have some upcoming reasons to allow the caller to decide that instead, so make the maximum number of datagrams a parameter for both of them. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
-rw-r--r--udp.c31
-rw-r--r--udp_vu.c6
-rw-r--r--udp_vu.h3
3 files changed, 24 insertions, 16 deletions
diff --git a/udp.c b/udp.c
index 4d32124..0f09e67 100644
--- a/udp.c
+++ b/udp.c
@@ -741,22 +741,17 @@ void udp_listen_sock_handler(const struct ctx *c,
* udp_buf_reply_sock_data() - Handle new data from flow specific socket
* @c: Execution context
* @s: Socket to read data from
+ * @n: Maximum number of datagrams to forward
* @tosidx: Flow & side to forward data from @s to
*
* Return: true on success, false if can't forward from socket to flow's pif
*/
-static bool udp_buf_reply_sock_data(const struct ctx *c,
- int s, flow_sidx_t tosidx)
+static bool udp_buf_reply_sock_data(const struct ctx *c, int s, int n,
+ flow_sidx_t tosidx)
{
const struct flowside *toside = flowside_at_sidx(tosidx);
uint8_t topif = pif_at_sidx(tosidx);
- /* For not entirely clear reasons (data locality?) pasta gets better
- * throughput if we receive tap datagrams one at a time. For small
- * splice datagrams throughput is slightly better if we do batch, but
- * it's slightly worse for large splice datagrams. Since we don't know
- * the size before we receive, always go one at a time for pasta mode.
- */
- int n = (c->mode == MODE_PASTA ? 1 : UDP_MAX_FRAMES), i;
+ int i;
if ((n = udp_sock_recv(c, s, udp_mh_recv, n)) <= 0)
return true;
@@ -801,6 +796,14 @@ void udp_sock_handler(const struct ctx *c, union epoll_ref ref,
}
if (events & EPOLLIN) {
+ /* For not entirely clear reasons (data locality?) pasta gets
+ * better throughput if we receive tap datagrams one at a
+ * time. For small splice datagrams throughput is slightly
+ * better if we do batch, but it's slightly worse for large
+ * splice datagrams. Since we don't know the size before we
+ * receive, always go one at a time for pasta mode.
+ */
+ size_t n = (c->mode == MODE_PASTA ? 1 : UDP_MAX_FRAMES);
flow_sidx_t tosidx = flow_sidx_opposite(ref.flowside);
int s = ref.fd;
bool ret;
@@ -808,10 +811,12 @@ void udp_sock_handler(const struct ctx *c, union epoll_ref ref,
flow_trace(uflow, "Received data on reply socket");
uflow->ts = now->tv_sec;
- if (c->mode == MODE_VU)
- ret = udp_vu_reply_sock_data(c, s, tosidx);
- else
- ret = udp_buf_reply_sock_data(c, s, tosidx);
+ if (c->mode == MODE_VU) {
+ ret = udp_vu_reply_sock_data(c, s, UDP_MAX_FRAMES,
+ tosidx);
+ } else {
+ ret = udp_buf_reply_sock_data(c, s, n, tosidx);
+ }
if (!ret) {
flow_err(uflow, "Unable to forward UDP");
diff --git a/udp_vu.c b/udp_vu.c
index 5faf1e1..b2618b3 100644
--- a/udp_vu.c
+++ b/udp_vu.c
@@ -257,11 +257,13 @@ void udp_vu_listen_sock_data(const struct ctx *c, union epoll_ref ref,
* udp_vu_reply_sock_data() - Handle new data from flow specific socket
* @c: Execution context
* @s: Socket to read data from
+ * @n: Maximum number of datagrams to forward
* @tosidx: Flow & side to forward data from @s to
*
* Return: true on success, false if can't forward from socket to flow's pif
*/
-bool udp_vu_reply_sock_data(const struct ctx *c, int s, flow_sidx_t tosidx)
+bool udp_vu_reply_sock_data(const struct ctx *c, int s, int n,
+ flow_sidx_t tosidx)
{
const struct flowside *toside = flowside_at_sidx(tosidx);
bool v6 = !(inany_v4(&toside->eaddr) && inany_v4(&toside->oaddr));
@@ -272,7 +274,7 @@ bool udp_vu_reply_sock_data(const struct ctx *c, int s, flow_sidx_t tosidx)
if (pif_at_sidx(tosidx) != PIF_TAP)
return false;
- for (i = 0; i < UDP_MAX_FRAMES; i++) {
+ for (i = 0; i < n; i++) {
ssize_t dlen;
int iov_used;
diff --git a/udp_vu.h b/udp_vu.h
index 6d541a4..c897c36 100644
--- a/udp_vu.h
+++ b/udp_vu.h
@@ -8,6 +8,7 @@
void udp_vu_listen_sock_data(const struct ctx *c, union epoll_ref ref,
const struct timespec *now);
-bool udp_vu_reply_sock_data(const struct ctx *c, int s, flow_sidx_t tosidx);
+bool udp_vu_reply_sock_data(const struct ctx *c, int s, int n,
+ flow_sidx_t tosidx);
#endif /* UDP_VU_H */