From: Stefano Brivio <sbrivio@redhat.com>
To: Laurent Vivier <lvivier@redhat.com>
Cc: passt-dev@passt.top, Jon Maloy <jmaloy@redhat.com>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH v5 4/7] tcp, flow: Replace per-connection in_epoll flag with an epollid in flow_common
Date: Thu, 30 Oct 2025 18:00:04 +0100 [thread overview]
Message-ID: <20251030180004.3336c2bb@elisabeth> (raw)
In-Reply-To: <20251021210116.314674-5-lvivier@redhat.com>
On Tue, 21 Oct 2025 23:01:13 +0200
Laurent Vivier <lvivier@redhat.com> wrote:
> diff --git a/flow.h b/flow.h
> index ef138b83add8..2c58b30ffc6a 100644
> --- a/flow.h
> +++ b/flow.h
> @@ -177,6 +177,7 @@ int flowside_connect(const struct ctx *c, int s,
> * @type: Type of packet flow
> * @pif[]: Interface for each side of the flow
> * @side[]: Information for each side of the flow
> + * @epollid: epollfd identifier, or EPOLLFD_ID_INVALID
> */
> struct flow_common {
> #ifdef __GNUC__
> @@ -192,8 +193,15 @@ struct flow_common {
> #endif
> uint8_t pif[SIDES];
> struct flowside side[SIDES];
> +#define EPOLLFD_ID_BITS 8
> + unsigned int epollid:EPOLLFD_ID_BITS;
> };
Just to confirm, on top of Jon's series (adding tap_omac[6] before
this):
struct tcp_tap_conn {
struct flow_common f; /* 0 84 */
/* --- cacheline 1 boundary (64 bytes) was 20 bytes ago --- */
[...]
/* size: 128, cachelines: 2, members: 19 */
/* sum members: 115 */
/* sum bitfield members: 97 bits, bit holes: 1, sum bit holes: 7 bits */
};
...perfect. Tight but we still have 7 bits (in a single chunk) should
we ever need something else.
--
Stefano
next prev parent reply other threads:[~2025-10-30 17:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-21 21:01 [PATCH v5 0/7] Refactor epoll handling in preparation for multithreading Laurent Vivier
2025-10-21 21:01 ` [PATCH v5 1/7] util: Simplify epoll_del() interface to take epollfd directly Laurent Vivier
2025-10-21 21:01 ` [PATCH v5 2/7] epoll_ctl: Extract epoll operations Laurent Vivier
2025-10-23 1:29 ` David Gibson
2025-10-21 21:01 ` [PATCH v5 3/7] util: Move epoll registration out of sock_l4_sa() Laurent Vivier
2025-10-21 21:01 ` [PATCH v5 4/7] tcp, flow: Replace per-connection in_epoll flag with an epollid in flow_common Laurent Vivier
2025-10-23 1:39 ` David Gibson
2025-10-30 17:00 ` Stefano Brivio [this message]
2025-10-21 21:01 ` [PATCH v5 5/7] icmp: Use epoll instance management for ICMP flows Laurent Vivier
2025-10-21 21:01 ` [PATCH v5 6/7] udp: Use epoll instance management for UDP flows Laurent Vivier
2025-10-23 1:40 ` David Gibson
2025-10-21 21:01 ` [PATCH v5 7/7] passt: Move main event loop processing into passt_worker() Laurent Vivier
2025-10-23 1:42 ` David Gibson
2025-10-30 17:00 ` [PATCH v5 0/7] Refactor epoll handling in preparation for multithreading 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=20251030180004.3336c2bb@elisabeth \
--to=sbrivio@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=jmaloy@redhat.com \
--cc=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).