On Wed, 16 Apr 2025 14:55:43 -0700, Andrii Nakryiko <[email protected]> 
wrote:

[......]
> I'm surprised these two are not part of bpf_base_func_proto, tbh...
> maybe let's move them there while we are cleaning all this up?
> 
> pw-bot: cr
> 
> > -       case BPF_FUNC_trace_printk:
> > -               return bpf_get_trace_printk_proto();
> >         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.
> > -       case BPF_FUNC_get_numa_node_id:
> > -               return &bpf_get_numa_node_id_proto;
> >         case BPF_FUNC_perf_event_read:
> >                 return &bpf_perf_event_read_proto;


Reply via email to