Daniel Borkmann <dan...@iogearbox.net> writes: > On 06/02/2018 06:22 AM, Daniel Borkmann wrote: >> On 05/31/2018 11:44 AM, Toke Høiland-Jørgensen wrote: >>> Song Liu <liu.song....@gmail.com> writes: >>> >>>> On Wed, May 30, 2018 at 9:45 AM, Toke Høiland-Jørgensen <t...@toke.dk> >>>> wrote: >>>>> This adds an example program showing how to sample packets from XDP using >>>>> the perf event buffer. The example userspace program just prints the >>>>> ethernet header for every packet sampled. >>>>> >>>>> Most of the userspace code is borrowed from other examples, most notably >>>>> trace_output. >>>>> >>>>> Note that the example only works when everything runs on CPU0; so >>>>> suitable smp_affinity needs to be set on the device. Some drivers seem >>>>> to reset smp_affinity when loading an XDP program, so it may be >>>>> necessary to change it after starting the example userspace program. >>>> >>>> Why does this only works when everything runs on CPU0? Is this >>>> something we can improve? >>> >>> Yeah, good question. Basically, the call from XDP to >>> bpf_perf_event_output() will fail with -EOPNOTSUPP. I tracked this down >>> to this if statement in __bpf_perf_event_output() in bpf_trace.c: >>> >>>> if (unlikely(event->oncpu != cpu)) >>>> return -EOPNOTSUPP; >>> >>> I *think* that the way to fix this is for the userspace program to open >>> a perf file descriptor for each CPU in the system and poll all of them, >>> in which case the XDP program can pass the BPF_F_CURRENT_CPU flag to >>> access the right one. >> That is correct, you need one perf fd per cpu, and map them accordingly >> into the map slots when you use BPF_F_CURRENT_CPU. > > Given this is a sample that users are likely to copy from, I think it would > be great if you could fix this up so you can just pass in BPF_F_CURRENT_CPU > eventually. Thanks for working on this, Toke!
You're welcome! And yup, I was planning to. I'll need to add a new function to the trace helpers that can poll more than one fd; just haven't gotten around to it yet. :) -Toke
