On 08/10/2025 02:24, David Gibson wrote:
On Tue, Oct 07, 2025 at 03:26:23PM +0200, Laurent Vivier wrote:
On 07/10/2025 08:07, David Gibson wrote:
On Fri, Oct 03, 2025 at 05:27:15PM +0200, Laurent Vivier wrote:
The in_epoll boolean flag in tcp_tap_conn and tcp_splice_conn only tracked whether a connection was registered with epoll, not which epoll instance. This limited flexibility for future multi-epoll support.
Replace the boolean with an epollfd field in flow_common that serves dual purpose: zero indicates not registered (replacing in_epoll=false), non-zero
Don't use 0, since that's a valid fd.
stores the actual epoll fd (replacing in_epoll=true).
I am a bit nervous about adding 31-bits to every flow, since I think we're fairly close to a cacheline threshold.
I'm not sure we really can add any less to flow_common, though, given alignment.
Then again... we probably don't need 8 bites each for TYPE and STATE, so those could be packed tighter. Then we could use a limited-bits index into a table of epollfds, rather than a raw fd. Much uglier, but maybe worth it?
I tried the epollfds table. But it introduces complexity and a new shared data structure that we will need to manage correctly in the case of multithreading. I don't think it's the way to follow...
I was assuming it would be a write-once data structure, meaning multithreaded management shouldn't be too hard. But ok.
I'm going to try that anyway: for multiqueue I would need to store the queue id in flow_common, and I have an array of queues with the epollfd, so I'll have the indirection and the number of queues is limited so it would fit in 8-bit (or less). I prepare a v3 with this change. Thanks, Laurent