On 07/10/2025 11:51, Stefano Brivio wrote:
On Tue, 7 Oct 2025 17:07:37 +1100 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 mentioned to Laurent in our weekly call on Monday the same concern and that I would look into it (first step, I would say, actually check with pahole?) and, if it's an issue, into possible tricks to avoid making the struct too big. I still plan to do this.
I think it already doesn't fit in a cacheline: struct flow_common { enum flow_state state:8; /* 0: 0 4 */ enum flow_type type:8; /* 0: 8 4 */ /* Bitfield combined with next fields */ uint8_t pif[2]; /* 2 2 */ struct flowside side[2]; /* 4 72 */ /* size: 76, cachelines: 2, members: 4 */ /* last cacheline: 12 bytes */ }; Laurent