public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: Laurent Vivier <lvivier@redhat.com>
To: passt-dev@passt.top
Cc: Laurent Vivier <lvivier@redhat.com>
Subject: [PATCH 3/7] tcp_splice: Refactor tcp_splice_conn_epoll_events() to per-side computation
Date: Fri, 19 Dec 2025 17:45:14 +0100	[thread overview]
Message-ID: <20251219164518.930012-4-lvivier@redhat.com> (raw)
In-Reply-To: <20251219164518.930012-1-lvivier@redhat.com>

The function tcp_splice_conn_epoll_events() currently takes an array of
struct epoll_event and fills in the .events field for both sides using
flow_foreach_sidei() loops.

This works, but the function is doing two conceptually separate things
at once: computing events for side 0 and computing events for side 1.
The OUT_WAIT handling is particularly subtle, as it has cross-side
effects: when OUT_WAIT(sidei) is set, we add EPOLLOUT to ev[sidei] but
also remove EPOLLIN from ev[!sidei].

Refactor to make the function compute events for a single side at a
time, taking sidei as a parameter and returning uint32_t. This makes
the logic more focused and easier to follow. The cross-side effects of
OUT_WAIT are preserved by checking both OUT_WAIT(sidei) and
OUT_WAIT(!sidei) within each call.

The caller tcp_splice_epoll_ctl() now invokes the function twice, once
for each side, making the two-sided nature of the operation explicit.

No functional change.

Signed-off-by: Laurent Vivier <lvivier@redhat.com>
---
 tcp_splice.c | 33 ++++++++++++++-------------------
 1 file changed, 14 insertions(+), 19 deletions(-)

diff --git a/tcp_splice.c b/tcp_splice.c
index 440522449c13..bf4ff466de07 100644
--- a/tcp_splice.c
+++ b/tcp_splice.c
@@ -114,29 +114,23 @@ static struct tcp_splice_conn *conn_at_sidx(flow_sidx_t sidx)
  * @events:	Connection event flags
  * @ev:		Events to fill in, 0 is accepted socket, 1 is connecting socket
  */
-static void tcp_splice_conn_epoll_events(uint16_t events,
-					 struct epoll_event ev[])
+static uint32_t tcp_splice_conn_epoll_events(uint16_t events, unsigned sidei)
 {
-	unsigned sidei;
-
-	flow_foreach_sidei(sidei)
-		ev[sidei].events = 0;
+	uint32_t e = 0;
 
 	if (events & SPLICE_ESTABLISHED) {
-		flow_foreach_sidei(sidei) {
-			if (!(events & FIN_SENT(!sidei)))
-				ev[sidei].events = EPOLLIN | EPOLLRDHUP;
-		}
-	} else if (events & SPLICE_CONNECT) {
-		ev[1].events = EPOLLOUT;
+		if (!(events & FIN_SENT(!sidei)))
+			e = EPOLLIN | EPOLLRDHUP;
+	} else if (sidei == 1 && events & SPLICE_CONNECT) {
+		e = EPOLLOUT;
 	}
 
-	flow_foreach_sidei(sidei) {
-		if (events & OUT_WAIT(sidei)) {
-			ev[sidei].events |= EPOLLOUT;
-			ev[!sidei].events &= ~EPOLLIN;
-		}
-	}
+	if (events & OUT_WAIT(sidei))
+		e |= EPOLLOUT;
+	if (events & OUT_WAIT(!sidei))
+		e &= ~EPOLLIN;
+
+	return e;
 }
 
 /**
@@ -161,7 +155,8 @@ static int tcp_splice_epoll_ctl(const struct ctx *c,
 	struct epoll_event ev[SIDES] = { { .data.u64 = ref[0].u64 },
 					 { .data.u64 = ref[1].u64 } };
 
-	tcp_splice_conn_epoll_events(conn->events, ev);
+	ev[0].events = tcp_splice_conn_epoll_events(conn->events, 0);
+	ev[1].events = tcp_splice_conn_epoll_events(conn->events, 1);
 
 
 	if (epoll_ctl(epollfd, m, conn->s[0], &ev[0]) ||
-- 
2.51.1


  parent reply	other threads:[~2025-12-19 16:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-19 16:45 [PATCH 0/7] flow: Introduce flow_epoll_set() to centralize epoll operations Laurent Vivier
2025-12-19 16:45 ` [PATCH 1/7] tcp: Update EPOLL_TYPE_TCP_TIMER fd Laurent Vivier
2025-12-19 16:45 ` [PATCH 2/7] udp_flow: Assign socket to flow inside udp_flow_sock() Laurent Vivier
2025-12-19 16:45 ` Laurent Vivier [this message]
2025-12-19 16:45 ` [PATCH 4/7] flow: Introduce flow_epoll_set() to centralize epoll operations Laurent Vivier
2025-12-19 16:45 ` [PATCH 5/7] flow: Use epoll_id_to_fd[EPOLLFD_ID_DEFAULT] in flow_epollid_set() Laurent Vivier
2025-12-19 16:45 ` [PATCH 6/7] flow: Compute epoll events inside flow_epoll_set() Laurent Vivier
2025-12-19 16:45 ` [PATCH 7/7] flow: Have flow_epoll_set() retrieve file descriptor from flow structure Laurent Vivier

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=20251219164518.930012-4-lvivier@redhat.com \
    --to=lvivier@redhat.com \
    --cc=passt-dev@passt.top \
    /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).