On Mon, Jun 18, 2018 at 3:47 AM Toke Høiland-Jørgensen <toke@xxxxxxx> wrote: > > Zvi Effron <zeffron@xxxxxxxxxxxxx> writes: > > > On Mon, Jun 18, 2018 at 12:41 AM Jesper Dangaard Brouer > > <brouer@xxxxxxxxxx> wrote: > >> > >> On Sun, 17 Jun 2018 18:07:02 -0700 > >> Zvi Effron <zeffron@xxxxxxxxxxxxx> wrote: > >> > >> > Hi XDPeople! > >> > > >> > In /include/uapi/linux/bpf.h, (in 4.18-rc1) the comment describing > >> > bpf_perf_event_output says: > >> > > >> > /* > >> > * Note that this helper is not restricted to tracing use cases > >> > * and can be used with programs attached to TC or XDP as well, > >> > * where it allows for passing data to user space listeners. Data > >> > * can be: > >> > * > >> > * * Only custom structs, > >> > * * Only the packet payload, or > >> > * * A combination of both. > >> > */ > >> > > >> > This seems to imply that for both TC and XDP, the packet can be used > >> > for passing data. When I try this, the verifier rejects the program > >> > with "helper access to the packet is not allowed". Looking through the > >> > kernel it doesn't look like bpf_perf_output_event has been tagged with > >> > the appropriate metadata to allow it to access the packet structure, > >> > either for TC or for XDP. Neither bpf_skb_event_output_proto nor > >> > bpf_xdp_event_output_proto have pkt_acess set to true. Is the > >> > documentation incorrect, should that metadata be updated to allow > >> > packet access, or is there something I'm missing? > >> > >> Toke (Cc'ed) recently posted a samples/bpf/ program to the kernel that > >> implement this (but it didn't reach the merge window). Thus, I assume > >> that this works... > >> > >> http://lkml.kernel.org/r/152830792912.21161.3609946361971472545.stgit@alrua-kau > > > > Thank you for the example. I was trying to pass the packet as the > > event metadata, but it looks like the correct way is to simply pass > > the length as the upper 32 bits of the flags. Might be beneficial to > > update the documentation in bpf.h to say that instead of just having > > some samples with comments. But that example in the samples folder > > with the comment explaining the flags in more detail is super useful. > > > > Interestingly, even without trying that, I'm now getting ENOTSUPP even > > if continue outputting the string I was before without any packet > > data. As far as I can tell, that means I'm somehow hitting the > > implementation of bpf_perf_output() in kernel/bpf/core.c instead of > > the one in kernel/trace/bpf_trace.c. I'm not sure what changed as I > > was able to emit events before. I've tried rebuilding my VM to negate > > any changes made by installing bcc (I'm using Fedora-29 from rawhide, > > last known good from 2018-06-04). > > > > I'll keep investigating, but if anyone has any ideas, they'd be > > appreciated. > > Are you passing BPF_F_CURRENT_CPU in flags from XDP? Perf does not > support sending messages to perf fds that are bound to a different CPU. > And since you don't control which CPU the XDP program is run on (unless > you pin all RXQs to the same CPU), you need to handle this. > > BPF_F_CURRENT_CPU makes perf index the map of perf fds by the CPU num, > so you'll need to fill the map with as many fds as you have CPUs. The > userspace component of the example will do this. I guess I should resend > the patch now that rc1 is out... That's exactly what it was. I'd forgotten I'd recently bumped the CPU count on the VM to 2. XDP program was running on CPU 1, but I'd only configured the map to hold an fd for CPU 0. Thanks for all of the help, everyone! --Zvi > -Toke
|