On 06/04/2018 03:02 PM, Toke Høiland-Jørgensen wrote:

Daniel Borkmann [off-list ref] writes:

quoted

On 06/02/2018 06:22 AM, Daniel Borkmann wrote:

quoted

On 05/31/2018 11:44 AM, Toke Høiland-Jørgensen wrote:

quoted

Song Liu [off-list ref] writes:

quoted

On Wed, May 30, 2018 at 9:45 AM, Toke Høiland-Jørgensen [off-list ref] wrote:

quoted

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:

quoted

	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. :)

Ok, great, looking forward!

Cheers,
Daniel