-
Notifications
You must be signed in to change notification settings - Fork 10
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
net: introduce input_buffer_factory concept. #6
base: ceph-octopus
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -129,6 +129,22 @@ public: | |
void close(); | ||
}; | ||
|
||
class input_buffer_factory { | ||
public: | ||
using buffer_t = temporary_buffer<char>; | ||
|
||
virtual ~input_buffer_factory() = default; | ||
/// Provide a rx buffer. Implementation is responsible for determining its size | ||
/// and memory. This is useful when a network stack implementation does not put | ||
/// extra requirements on these factors. The POSIX stack is the example here. | ||
/// \param allocator Memory allocator \c connected_socket implementation prefers. | ||
/// Maybe nullptr. | ||
virtual buffer_t create(compat::polymorphic_allocator<char>* allocator) = 0; | ||
|
||
// Give back to the factory unused part of a buffer obtained from it | ||
virtual void return_unused(buffer_t&& buf) = 0; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Curious about how to make use of the unused tail of the rx buffer, feed back to the data_souce later? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yup, that's the idea. For huge chunks even the POSIX stack tends to fragment the output. This is likely because of the future<size_t>
reactor::read_some(pollable_fd_state& fd, void* buffer, size_t len) {
return readable(fd).then([this, &fd, buffer, len] () mutable {
auto r = fd.fd.read(buffer, len);
// ...
} |
||
}; | ||
|
||
} /* namespace net */ | ||
|
||
/// \addtogroup networking-module | ||
|
@@ -156,7 +172,10 @@ public: | |
/// Gets the input stream. | ||
/// | ||
/// Gets an object returning data sent from the remote endpoint. | ||
input_stream<char> input(); | ||
/// \param ibf_hint optional factory of rx buffers. The decision | ||
/// whether to use the factory is opt to an implementation of \c | ||
/// connected_socket. | ||
input_stream<char> input(net::input_buffer_factory* ibf_hint = nullptr); | ||
/// Gets the output stream. | ||
/// | ||
/// Gets an object that sends data to the remote endpoint. | ||
|
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.
I understand this is not the final implementation, just for the record:
For input_buffer_factory of v2 protocol,
return seastar::make_temporary_buffer<char>(allocator, get_current_msg_size() + FRAME_PLAIN_EPILOGUE_SIZE + FRAME_PREAMBLE_SIZE + 41)
would be too simple, because it is the 3rd segment (DATA) which needs to be page-aligned.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.
Yes, you're entirely correct. We would need to allocate a bigger buffer and
::trim_front
it accordingly.