On Thu, 17 Apr 2025 17:52:45 +0800 Feng Yang wrote:
> > > case BPF_FUNC_get_smp_processor_id:
> > > return &bpf_get_smp_processor_id_proto;
> >
> > this one should be cleaned up as well and
> > bpf_get_smp_processor_id_proto removed. All BPF programs either
> > disable CPU preemption or CPU migration, so bpf_base_func_proto's
> > implementation should work just fine (but please do it as a separate
> > patch)
> >
> BPF_CALL_0(bpf_get_smp_processor_id)
> {
> return smp_processor_id();
> }
> const struct bpf_func_proto bpf_get_smp_processor_id_proto = {
> .func = bpf_get_smp_processor_id,
> .gpl_only = false,
> .ret_type = RET_INTEGER,
> .allow_fastcall = true,
> };
> When attempting to remove bpf_get_smp_processor_id_proto,
> it was observed that bpf_get_smp_processor_id is extensively used.
> Should we also replace all instances of bpf_get_smp_processor_id with
> bpf_get_raw_cpu_id in these cases?
>
> For example:
> #define ___BPF_FUNC_MAPPER(FN, ctx...) \
> ......
> FN(get_smp_processor_id, 8, ##ctx) \
> samples/bpf/sockex3_kern.c:
> static struct globals *this_cpu_globals(void)
> {
> u32 key = bpf_get_smp_processor_id();
> return bpf_map_lookup_elem(&percpu_map, &key);
> }
> and so on......
> Thanks.
I think I understand the issue now: removing this bpf_get_smp_processor_id has
no impact.
For the code:
case BPF_FUNC_get_smp_processor_id:
return &bpf_get_raw_smp_processor_id_proto;
This configuration allows bpf_get_smp_processor_id to actually invoke the
bpf_get_raw_smp_processor_id_proto function implementation.
Thanks.
