Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New eBPF API to insert events into ring buffer eBPF map. #3572

Closed
shankarseal opened this issue May 22, 2024 · 6 comments · Fixed by #3689
Closed

New eBPF API to insert events into ring buffer eBPF map. #3572

shankarseal opened this issue May 22, 2024 · 6 comments · Fixed by #3689
Assignees
Labels
enhancement New feature or request P1 triaged Discussed in a triage meeting
Milestone

Comments

@shankarseal
Copy link
Collaborator

A common use case of an eBPF ring buffer map to use as a queue of events generated by eBPF programs that can be read in-order by user space applications. The API request is to let user space applications to write events into the ring buffer map, such that events by eBPF programs in kernel and user space applications are interleaved in the order they were generated, that can be consumed by another user space application

@dthaler
Copy link
Collaborator

dthaler commented May 23, 2024

I would suggest asking on the Linux bpf list or slack channel if there is a way to do this scenario on Linux.
There might be some existing answer. Or there might be reasons to not do this but take some other approach.
Before going down this road, we should understand how to make a cross-platform solution rather than designing a Windows-only one.

@dthaler dthaler added the enhancement New feature or request label May 23, 2024
@dahavey dahavey added the triaged Discussed in a triage meeting label May 28, 2024
@dahavey dahavey added this to the 2406 milestone May 28, 2024
@dahavey dahavey added the P1 label May 28, 2024
@dthaler
Copy link
Collaborator

dthaler commented May 28, 2024

Per email thread with Andrii, the correct map type is BPF_MAP_TYPE_USER_RINGBUF and the UM APIs are:

struct ring_buffer_user *
ring_buffer_user__new(int map_fd,
                      const struct ring_buffer_user_opts *opts);
void ring_buffer_user__free(struct ring_buffer_user *rb);
void *ring_buffer_user__reserve(struct ring_buffer_user *rb,
				uint32_t size);
void *ring_buffer_user__poll(struct ring_buffer_user *rb, uint32_t size,
			     int timeout_ms);
void ring_buffer_user__discard(struct ring_buffer_user *rb, void *sample);
void ring_buffer_user__submit(struct ring_buffer_user *rb, void *sample);

per https://lwn.net/Articles/907056/

@dthaler
Copy link
Collaborator

dthaler commented Jun 17, 2024

@shankarseal shankarseal modified the milestones: 2406, 2407 Jun 29, 2024
@shankarseal
Copy link
Collaborator Author

@dthaler - based on the latest on this thread I think Andrii does not have any objections to the API. Although he does not have time to work on this.

The IOCTL approach that we would take in Windows is likely not going to work on Linux - so we would have a different implementation in Linux. The alternative that I proposed for Linux (a program invoked by bpf_prog_test that writes into a ring buffer) is cumbersome as pointed out by Andrii.

Dave, please approve the use of this API, otherwise the only way forward will be the above cumbersome workaround.

@dthaler
Copy link
Collaborator

dthaler commented Jul 2, 2024

I didn't see any agreement on the API from Andrii or others, but I also saw no explanation as to why it would not be appropriate on Linux. So I'd keep it a windows-only api (meaning starting with ebpf_ not bpf_) for now so that if there is later work, we can switch.

@shankarseal
Copy link
Collaborator Author

Raised #3689 . I could not re-use the older PR #3562 which has some comments that I had resolved. And the ongoing discussion about linux APIs are captured in this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request P1 triaged Discussed in a triage meeting
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants