[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHsH6GtmhP=hZcf2Qv=21dAOSb5dD4GDa+QYdLFz9_FsCZq6tA@mail.gmail.com>
Date: Thu, 7 Dec 2023 13:08:08 -0800
From: Eyal Birger <eyal.birger@...il.com>
To: Daniel Xu <dxu@...uu.xyz>
Cc: Herbert Xu <herbert@...dor.apana.org.au>,
Steffen Klassert <steffen.klassert@...unet.com>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, alexei.starovoitov@...il.com,
devel@...ux-ipsec.org, eddyz87@...il.com, edumazet@...gle.com,
Eyal Birger <eyal@...anetworks.com>, yonghong.song@...ux.dev, kuba@...nel.org,
bpf@...r.kernel.org, pabeni@...hat.com, davem@...emloft.net
Subject: Re: [devel-ipsec] [PATCH bpf-next v4 01/10] xfrm: bpf: Move
xfrm_interface_bpf.c to xfrm_bpf.c
Hi Daniel,
On Thu, Dec 7, 2023 at 3:52 AM Steffen Klassert via Devel
<devel@...ux-ipsec.org> wrote:
>
> On Mon, Dec 04, 2023 at 01:56:21PM -0700, Daniel Xu wrote:
> > This commit moves the contents of xfrm_interface_bpf.c into a new file,
> > xfrm_bpf.c This is in preparation for adding more xfrm kfuncs. We'd like
> > to keep all the bpf integrations in a single file.
This takes away the nice ability to reload the xfrm interface
related kfuncs when reloading the xfrm interface.
I also find it a little strange that the kfuncs would be available
when the xfrm interface isn't loaded.
So imho it makes sense that these kfuncs would be built
as part of the module and not as part of the core.
Eyal.
Powered by blists - more mailing lists