Introduce BPF Streams abstraction #1284

etsal · 2025-12-09T18:30:54Z

Add libbpf-rs support for interacting with BPF streams from Rust code. The interface provides the option to either directly specify the prog fd/stream id, or to hide the details behind a Stream abstraction.

danielocfb

Hi @etsal, thanks for the pull request. Left a few comments with suggestions for improvement/clarifying questions. Can you please make sure to add tests for the functionality?

In general it feels as if Stream should likely implement io::Read to enable proper interop with other Rust components.

libbpf-rs/src/streams.rs

etsal · 2025-12-10T00:29:39Z

Thank you for the review, I will update the PR accordingly and post here to confirm it's ready for review. Ack to all comments, though I have a couple followup questions (inline).

etsal · 2025-12-10T20:41:25Z

Updated the code and added tests. The interface now presents the streams only indirectly and without exposing the type itself unless the user opts to create an instance directly. I think the code now is more idiomatic and looks a lot less like C.

etsal · 2025-12-10T21:42:24Z

The failing tests looks like are caused the test VMs' kernel being < 6.17?

danielocfb

This looks good to me now. Left a few more coments/questions/suggestions; please take another look. Please also fix CI so we can merge.

danielocfb · 2025-12-10T21:44:56Z

libbpf-rs/src/streams.rs

+            libbpf_sys::bpf_prog_stream_read(
+                self.prog_fd.as_raw_fd(),
+                self.stream_id,
+                buf.as_mut_ptr() as *mut c_void,


Suggested change

buf.as_mut_ptr() as *mut c_void,

buf.as_mut_ptr().cast()

danielocfb · 2025-12-10T21:45:23Z

libbpf-rs/src/streams.rs

+                self.stream_id,
+                buf.as_mut_ptr() as *mut c_void,
+                buf.len().try_into().unwrap(),
+                &mut c_opts as *mut bpf_prog_stream_read_opts,


Suggested change

&mut c_opts as *mut bpf_prog_stream_read_opts,

&raw mut c_opts,

danielocfb · 2025-12-10T21:52:43Z

libbpf-rs/tests/test_streams.rs

+    let mut stdout = prog.stdout();
+    let mut buf = [0u8; 1024];
+
+    // The read itself should succeed and return 0 bytes


Am I misreading or does the comment state the opposite of what is being asserted?

You're right, the condition in the assert!() was wrong.

danielocfb · 2025-12-10T22:00:22Z

libbpf-rs/tests/bin/src/stream.bpf.c

+
+volatile u64 i;
+
+/* Trigger a may_goto timeout to emit a streams error. */


So this may_goto timeout is a way to force the kernel to emit data to stderr, is that how it works? And there is no way to write to a stream directly? And what are the requirements for may_goto to be available? Is it just a certain LLVM version? Or kernel config? It's also not exactly clear what happens if it's not available. Will the test still work?

If there is no easier way to trigger a stream write, can you please expand the comment a bit to make it clear who does what and in response to what exactly?

Yeah pretty much, unfortunatley there isn't a straightforward way to directly emit to stdout/stderr. Only stderr can contain data, and that is generated by the BPF runtime in the kernel rather than the program itself. I'll expand the comment to explain.

For may_goto: It's been available since 6.9, and it works regardless of compiler version because there are compatiblity macros to handle older LLVM versions.

You could use bpf_stream_printk (convenience macro over bpf_stream_vprintk) to write to either stream, triggering a may_goto timeout error also means a 250ms delay.

danielocfb · 2025-12-10T22:01:19Z

libbpf-rs/src/program.rs

    }
 }

-


Would be good to remove spurious formatting changes. Thanks!

Sorry, I ran rustfmt on the file directly and there seem to be some extra newlines already present in the file. I'll remove them from the diff.

danielocfb · 2025-12-10T22:06:41Z

The failing tests looks like are caused the test VMs' kernel being < 6.17?

If that's the case you can mark them as ignored for now.

libbpf-rs/libbpf-rs/tests/test.rs

Line 1702 in e0caff4

#[ignore = "requires kernel with kprobe multi support"]

At the moment we just use whatever kernel the Ubuntu image ships with. Right now that seems to be 6.11 (https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md)

Add an abstraction for reading BPF Streams. This commit introduces the wrappers around the libbpf-sys method. Signed-off-by: Emil Tsalapatis <[email protected]>

Add tests for BPF Streams. The tests access both the stdout and stderr streams, and ensure the code works regardless of whether there is ready data. Signed-off-by: Emil Tsalapatis <[email protected]>

etsal · 2025-12-12T18:44:06Z

Clippy seems to be failing on unrelated code.

etsal · 2025-12-12T18:50:31Z

Not sure why clippy is hitting these errors, they are for pre-existing code.

danielocfb · 2025-12-12T22:43:32Z

It's failing because you don't use all functions provided by the common module, which your new test_stream module uses, so Rust complains about unused code.

I fixed it up and merged. Thanks for the pull request!

etsal · 2025-12-12T22:57:55Z

Thank you for the detailed feedback!

Add a CHANGELOG entry for pull request libbpf#1284, which added support for accessing BPF stdout and stderr streams. Signed-off-by: Daniel Müller <[email protected]>

Add a CHANGELOG entry for pull request #1284, which added support for accessing BPF stdout and stderr streams. Signed-off-by: Daniel Müller <[email protected]>

etsal force-pushed the streams branch from 6da2bd8 to 252e8d1 Compare December 9, 2025 18:32

etsal mentioned this pull request Dec 9, 2025

[DRAFT] scx_arena: use libbpf-rs BPF streams instead of using libbpf_sys directly sched-ext/scx#3142

Open

danielocfb requested changes Dec 9, 2025

View reviewed changes

danielocfb reviewed Dec 9, 2025

View reviewed changes

libbpf-rs/src/streams.rs Outdated Show resolved Hide resolved

etsal force-pushed the streams branch from 252e8d1 to 753d381 Compare December 10, 2025 20:38

etsal force-pushed the streams branch 3 times, most recently from ad9d89b to 2b0bad2 Compare December 10, 2025 21:24

danielocfb approved these changes Dec 10, 2025

View reviewed changes

Introduce BPF Streams abstraction

bc159f9

Add an abstraction for reading BPF Streams. This commit introduces the wrappers around the libbpf-sys method. Signed-off-by: Emil Tsalapatis <[email protected]>

etsal force-pushed the streams branch from 2b0bad2 to b0f64d4 Compare December 12, 2025 18:32

Add tests for BPF Streams

b38db64

Add tests for BPF Streams. The tests access both the stdout and stderr streams, and ensure the code works regardless of whether there is ready data. Signed-off-by: Emil Tsalapatis <[email protected]>

etsal force-pushed the streams branch from b0f64d4 to b38db64 Compare December 12, 2025 18:36

danielocfb closed this Dec 12, 2025

danielocfb mentioned this pull request Dec 15, 2025

Add CHANGELOG entry for #1284 #1287

Merged

danielocfb pushed a commit that referenced this pull request Dec 15, 2025

Add CHANGELOG entry for #1284

d2fe5de

Add a CHANGELOG entry for pull request #1284, which added support for accessing BPF stdout and stderr streams. Signed-off-by: Daniel Müller <[email protected]>

	&mut c_opts as *mut bpf_prog_stream_read_opts,
	&raw mut c_opts,


		volatile u64 i;

		/* Trigger a may_goto timeout to emit a streams error. */

Introduce BPF Streams abstraction #1284

Introduce BPF Streams abstraction #1284

Conversation

etsal commented Dec 9, 2025

Uh oh!

danielocfb left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

etsal commented Dec 10, 2025

Uh oh!

etsal commented Dec 10, 2025

Uh oh!

etsal commented Dec 10, 2025

Uh oh!

danielocfb left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

danielocfb commented Dec 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

etsal commented Dec 12, 2025

Uh oh!

etsal commented Dec 12, 2025

Uh oh!

danielocfb commented Dec 12, 2025

Uh oh!

etsal commented Dec 12, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

danielocfb commented Dec 10, 2025 •

edited

Loading