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.

Sign up for GitHub

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

Jump to bottom

Feature request: Export io_uring_buf_ring #1143

Open
ryanseipp opened this issue Aug 29, 2024 · 2 comments · May be fixed by #1155
Open

Feature request: Export io_uring_buf_ring #1143

ryanseipp opened this issue Aug 29, 2024 · 2 comments · May be fixed by #1155

Comments

@ryanseipp
Copy link
Contributor

io_uring utilizes a struct called io_uring_buf_ring to register a ring buffer of io_uring_buf structs that contain a reference to slices of buffers that can be filled in certain operations. One operation that can utilize this is IoringOp::Recv with the IoringRecvFlags::MULTISHOT flag set. This can make for much more performant operations, especially for those using direct io, as the kernel can choose a buffer to utilize, allowing the application to have many more recv operations in flight than available buffers.

This struct was added to linux 5.19, and is defined here.

linux_raw_sys 0.4 exports this struct here, which contains an anonymous union and C flexible array member. libc does not export this type.

I see we hand-code structs instead of re-exporting them, seemingly because libc doesn't export those structs. So, I'm primarily looking for guidance on how to define the flexible array member. I'd be happy to contribute this struct if someone doesn't go for it first.
@sunfishcode
Copy link
Member

First, this is cool, thanks for working on this!

Currently rustix's io_uring API uses zero-length arrays, such as here. That is simple, however, that's not ergonomic as it requires users to use .as_ptr() and unsafe code and manual pointer arithmetic to access the contents.

I think it might be better to add a type like bindgen's __IncompleteArrayField to rustix's public API, and then use that to describe the flexible arrays. It still requires unsafe code, but it encapsulates the pointer arithmetic. Does that sound reasonable?

@ryanseipp
Copy link
Contributor Author

Adding an __IncompleteArrayField does sound reasonable to me. Don't think there's a way to avoid unsafe here, so providing a little more utility seems reasonable. I'll give this a go and see where we can get to.

Was going to ask about updating that cmd union member to use the new struct, but it seems we'd technically be reducing the type's API to one that's more restrictive, and would be a breaking change?

@ryanseipp ryanseipp linked a pull request Sep 7, 2024 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add io_uring_buf_ring struct ryanseipp/rustix
2 participants
@sunfishcode @ryanseipp