-
Notifications
You must be signed in to change notification settings - Fork 455
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
refactor(blob_io): use owned buffers #6660
refactor(blob_io): use owned buffers #6660
Conversation
We can probably get rid of the entire trait, but, that's for another time.
…uilder-refactor' into problame/integrate-tokio-epoll-uring/write-path/simplify-write-at-api
This reverts commit b5a00b0.
…ath/refactor-blob-writer
2430 tests run: 2319 passed, 0 failed, 111 skipped (full report)Code coverage (full report)
The comment gets automatically updated with the latest test results
4227e42 at 2024-02-12T13:59:49.623Z :recycle: |
…ath/refactor-blob-writer
…ath/refactor-blob-writer
…kio-epoll-uring/write-path/refactor-blob-writer
…ath/refactor-blob-writer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seeing these parts for the first time, cannot spot any problems.
…kio-epoll-uring/write-path/refactor-blob-writer
io_buf, | ||
Err(Error::new( | ||
ErrorKind::Other, | ||
format!("blob too large ({} bytes)", len), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
format!("blob too large ({} bytes)", len), | |
format!("blob too large ({len} bytes)"), |
let mut len_buf = (len as u32).to_be_bytes(); | ||
len_buf[0] |= 0x80; | ||
io_buf.extend_from_slice(&len_buf[..]); | ||
self.write_all(io_buf).await |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the write call can be moved out of the if as both branches have it.
|
||
let mut io_buf = self.io_buf.take().expect("we always put it back below"); | ||
io_buf.clear(); | ||
let (io_buf, hdr_res) = async { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's not 100% clear to me why there is an async block here. It would be useful to have a comment that explains it also for other future readers. I suppose some ownership/borrow checker issue?
This PR refactors the `blob_io` code away from using slices towards taking owned buffers and return them after use. Using owned buffers will eventually allow us to use io_uring for writes. part of #6663 Depends on neondatabase/tokio-epoll-uring#43 The high level scheme is as follows: - call writing functions with the `BoundedBuf` - return the underlying `BoundedBuf::Buf` for potential reuse in the caller NB: Invoking `BoundedBuf::slice(..)` will return a slice that _includes the uninitialized portion of `BoundedBuf`_. I.e., the portion between `bytes_init()` and `bytes_total()`. It's a safe API that actually permits access to uninitialized memory. Not great. Another wrinkle is that it panics if the range has length 0. However, I don't want to switch away from the `BoundedBuf` API, since it's what tokio-uring uses. We can always weed this out later by replacing `BoundedBuf` with our own type. Created an issue so we don't forget: neondatabase/tokio-epoll-uring#46
For the record, @arpad-m and I had a call where I explained the questions above. |
The call addressed my first two concerns, which turn out to be due to shortcomings in the API. The three last comments in the review still apply though. Would be great to have a followup PR for them, but not extremely neccessary as they are just nits. |
This PR refactors the
blob_io
code away from using slices towards taking owned buffers and return them after use.Using owned buffers will eventually allow us to use io_uring for writes.
part of #6663
Depends on neondatabase/tokio-epoll-uring#43
The high level scheme is as follows:
BoundedBuf
BoundedBuf::Buf
for potential reuse in the callerNB: Invoking
BoundedBuf::slice(..)
will return a slice that includes the uninitialized portion ofBoundedBuf
.I.e., the portion between
bytes_init()
andbytes_total()
.It's a safe API that actually permits access to uninitialized memory.
Not great.
Another wrinkle is that it panics if the range has length 0.
However, I don't want to switch away from the
BoundedBuf
API, since it's what tokio-uring uses.We can always weed this out later by replacing
BoundedBuf
with our own type.Created an issue so we don't forget: neondatabase/tokio-epoll-uring#46