[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z8C5pznZoY6fuZyV@pop-os.localdomain>
Date: Thu, 27 Feb 2025 11:14:47 -0800
From: Cong Wang <xiyou.wangcong@...il.com>
To: Jakub Sitnicki <jakub@...udflare.com>
Cc: netdev@...r.kernel.org, bpf@...r.kernel.org, john.fastabend@...il.com,
zhoufeng.zf@...edance.com, zijianzhang@...edance.com,
Cong Wang <cong.wang@...edance.com>
Subject: Re: [Patch bpf-next 3/4] skmsg: use bitfields for struct sk_psock
On Thu, Feb 27, 2025 at 10:53:53AM +0100, Jakub Sitnicki wrote:
> On Wed, Feb 26, 2025 at 02:21 PM -08, Cong Wang wrote:
> > On Wed, Feb 26, 2025 at 02:49:17PM +0100, Jakub Sitnicki wrote:
> >> On Sat, Feb 22, 2025 at 10:30 AM -08, Cong Wang wrote:
> >> > From: Cong Wang <cong.wang@...edance.com>
> >> >
> >> > psock->eval can only have 4 possible values, make it 8-bit is
> >> > sufficient.
> >> >
> >> > psock->redir_ingress is just a boolean, using 1 bit is enough.
> >> >
> >> > Signed-off-by: Cong Wang <cong.wang@...edance.com>
> >> > ---
> >> > include/linux/skmsg.h | 4 ++--
> >> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/include/linux/skmsg.h b/include/linux/skmsg.h
> >> > index bf28ce9b5fdb..beaf79b2b68b 100644
> >> > --- a/include/linux/skmsg.h
> >> > +++ b/include/linux/skmsg.h
> >> > @@ -85,8 +85,8 @@ struct sk_psock {
> >> > struct sock *sk_redir;
> >> > u32 apply_bytes;
> >> > u32 cork_bytes;
> >> > - u32 eval;
> >> > - bool redir_ingress; /* undefined if sk_redir is null */
> >> > + unsigned int eval : 8;
> >> > + unsigned int redir_ingress : 1; /* undefined if sk_redir is null */
> >> > struct sk_msg *cork;
> >> > struct sk_psock_progs progs;
> >> > #if IS_ENABLED(CONFIG_BPF_STREAM_PARSER)
> >>
> >> Are you doing this bit packing to create a hole big enough to fit
> >> another u32 introduced in the next patch?
> >
> > Kinda, or at least trying to save some space for the next patch. I am
> > not yet trying to reorder them to make it more packed, because it can
> > be a separate patch.
>
> OK. Asking because the intention is not expressed in the description.
I will add it to the patch description for V2 (after collecting other
feedback).
>
> Nit: Why the switch to an implicitly sized integer type?
> It feels a bit silly when you can just declare an `u8 eval`.
I have no strong preference here, either should work. :)
Thanks.
Powered by blists - more mailing lists