[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zzrde4aJcmzjDnqI@gauss3.secunet.de>
Date: Mon, 18 Nov 2024 07:23:55 +0100
From: Steffen Klassert <steffen.klassert@...unet.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: David Miller <davem@...emloft.net>, Herbert Xu
<herbert@...dor.apana.org.au>, <netdev@...r.kernel.org>
Subject: Re: [PATCH 01/11] xfrm: Add support for per cpu xfrm state handling.
On Fri, Nov 15, 2024 at 06:09:08PM -0800, Jakub Kicinski wrote:
> On Fri, 15 Nov 2024 09:33:33 +0100 Steffen Klassert wrote:
> > + /* We need the cpu id just as a lookup key,
> > + * we don't require it to be stable.
> > + */
> > + pcpu_id = get_cpu();
> > + put_cpu();
>
> Why not smp_processor_id() ?
This might be executed in preemptable code sections,
smp_processor_id() will throw a warning if that happens.
Maybe raw_smp_processor_id() can be used instead here,
but was not sure if that's the right thing.
>
> > + if (attrs[XFRMA_SA_PCPU]) {
> > + x->pcpu_num = nla_get_u32(attrs[XFRMA_SA_PCPU]);
> > + if (x->pcpu_num >= num_possible_cpus())
> > + goto error;
> > + }
>
> cpu ids can be sparse, shouldn't it be checking if the CPU is online ?
I thought about that. But then we must wait for an IKE negotiation
before we can use a fresh booted cpu. If we pre-negotiate a SA,
the cpu can be used right away. I depends a bit on the usecase what's
preferred here.
Powered by blists - more mailing lists