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

libtock: add util/streaming_process_slice #492

Merged
merged 2 commits into from
Mar 4, 2025

Conversation

lschuermann
Copy link
Member

This adds userspace helpers implementing the "streaming process slice" contract as implemented in the Tock kernel in 1. Instead of working with two separate buffers, these helpers present an interface similar to a regular read-write allow based on a single buffer. Internally, this buffer is then subdivided into an "application-owned" and "kernel-owned" part which are swapped atomically. The caller is responsible for keeping a streaming_process_slice_state_t, and is provided with ephemeral references to the kernel-written payloads on each swap operation. The full, original buffer can be reclaimed by deinitializing the streaming_process_slice_state_t struct.

Currently, these helpers are quite minimal and do not expose the ability to set any optional flags (such as halt). They are tested to work against against the interface implemented in 1 (with the fix of 2 included) as part of the LwIP Ethernet tap-driver userspace app.

@lschuermann lschuermann force-pushed the dev/streaming-process-slice branch from e9a2c17 to c6ed0ed Compare February 16, 2025 20:28
@lschuermann lschuermann force-pushed the dev/streaming-process-slice branch from c6ed0ed to 3f29461 Compare February 16, 2025 20:36
@brghena brghena added the WG-Network In the purview of the Network working group. label Feb 16, 2025
@brghena brghena self-assigned this Feb 16, 2025
Copy link
Contributor

@brghena brghena left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes sense to me. Pretty reasonably clean interface, with an excellently documented implementation. A couple of questions for you.

@lschuermann lschuermann force-pushed the dev/streaming-process-slice branch 2 times, most recently from a3e0c8e to aa58332 Compare February 20, 2025 23:57
This adds userspace helpers implementing the "streaming process slice"
contract as implemented in the Tock kernel in [1]. Instead of working
with two separate buffers, these helpers present an interface similar
to a regular read-write allow based on a single buffer. Internally,
this buffer is then subdivided into an "application-owned" and
"kernel-owned" part which are swapped atomically. The caller is
responsible for keeping a `streaming_process_slice_state_t`, and is
provided with ephemeral references to the kernel-written payloads on
each swap operation. The full, original buffer can be reclaimed by
deinitializing the `streaming_process_slice_state_t` struct.

Currently, these helpers are quite minimal and do not expose the
ability to set any optional flags (such as `halt`). They are tested to
work against against the interface implemented in [1] (with the fix of
[2] included) as part of the LwIP Ethernet tap-driver userspace app.

[1]: tock/tock#4208
[2]: tock/tock#4343
lschuermann added a commit that referenced this pull request Feb 21, 2025
Instead of internally splitting a single buffer to create two halves
used in the streaming process slice abstraction, this changes it to
accept two separate buffers for the kernel- and application-owned
buffer respectively.

This was discussed on the pull request introducing this abstraction:
#492 (comment)

Suggested-by: Branden Ghena <[email protected]>
@lschuermann lschuermann force-pushed the dev/streaming-process-slice branch from aa58332 to 5c24a44 Compare February 21, 2025 00:02
Copy link
Contributor

@brghena brghena left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of changes for you.

I do think this is cleaner, although again if no one else cares I'm fine going with your single-buffer implementation instead.

brghena
brghena previously approved these changes Feb 24, 2025
Instead of internally splitting a single buffer to create two halves
used in the streaming process slice abstraction, this changes it to
accept two separate buffers for the kernel- and application-owned
buffer respectively.

This was discussed on the pull request introducing this abstraction:
#492 (comment)

Suggested-by: Branden Ghena <[email protected]>
@brghena brghena added this pull request to the merge queue Mar 4, 2025
Merged via the queue into master with commit 39f83a8 Mar 4, 2025
4 checks passed
@brghena brghena deleted the dev/streaming-process-slice branch March 4, 2025 04:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
last-call WG-Network In the purview of the Network working group.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants