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
librbd: scatter/gather support for the C API #13447
Conversation
|
retest this please |
69ba43c
to
6bf7123
Compare
| #define LIBRBD_VER_MINOR 1 | ||
| #define LIBRBD_VER_EXTRA 11 | ||
| #define LIBRBD_VER_MAJOR 1 | ||
| #define LIBRBD_VER_MINOR 12 |
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.
@dillaman Just wondering why minor is not reset when major is increased? And actually what was the reason to bump major? I thought it is only when API incompatibility is introduced, and this does not look like this case?
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.
Ah, I suppose there is no actual version major bump, LIBRBD_VER_MAJOR 0 just was a bug and now it matches librbd SOVERSION. BTW, shouldn't the library VERSION (which is 1.0.0 currently) match major.minor.extra?
|
|
@trociny unit test fixed by closing the image properly and updated the shared library version for consistency |
src/librbd/io/CopyupRequest.cc
Outdated
| @@ -204,7 +205,7 @@ void CopyupRequest::send() | |||
| << ", oid " << m_oid | |||
| << ", extents " << m_image_extents | |||
| << dendl; | |||
| AioImageRequest<>::aio_read(m_ictx->parent, comp, std::move(m_image_extents), | |||
| ImageRequest<>::aio_read(m_ictx->parent, comp, std::move(m_image_extents), | |||
| nullptr, &m_copyup_data, 0); | |||
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.
indentation
src/librbd/io/ObjectRequest.cc
Outdated
| uint64_t object_no, uint64_t object_off, | ||
| const ::SnapContext &snapc, | ||
| Context *completion) { | ||
| return new ObjectTruncateRequest(util::get_image_ctx(ictx), oid, object_no, | ||
| object_off, snapc, completion); |
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.
indentation
src/librbd/io/ObjectRequest.cc
Outdated
| const ceph::bufferlist &data, | ||
| const ::SnapContext &snapc, | ||
| Context *completion, int op_flags) { | ||
| return new ObjectWriteRequest(util::get_image_ctx(ictx), oid, object_no, | ||
| object_off, data, snapc, completion, op_flags); |
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.
indentation
src/librbd/io/ObjectRequest.cc
Outdated
| uint64_t object_len, | ||
| const ::SnapContext &snapc, | ||
| Context *completion) { | ||
| return new ObjectZeroRequest(util::get_image_ctx(ictx), oid, object_no, | ||
| object_off, object_len, snapc, completion); |
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.
indentation
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
The RBD C API now has scatter/gather IO support via the API. The C++ API uses bufferlists which can also support scatter/gather IO. Fixes: http://tracker.ceph.com/issues/13025 Signed-off-by: Jason Dillaman <dillaman@redhat.com>
|
@trociny updated |
|
@dillaman do you consider to use buffer::claim_buffer(https://github.com/ceph/ceph/blob/master/src/common/buffer.cc#L646) to solve data copy problem? example usage can be found at https://github.com/ceph/ceph/blob/master/src/msg/async/dpdk/DPDKStack.h#L116. deleter could be a lambda which called when ptr released |
|
@yuyuyu101 Cool -- didn't know that was already implemented. I brought up an option similar to this on the ceph-devel list [1] (combined w/ delaying the AioCompletion) and Sage mentioned that it would be possible for the memory reference to be held for a potentially long period of time (where such a completion delay wouldn't be feasible). |
|
@dillaman yes, we can't release memory with releasing AioCompletion. I suggest that user can provide with callback as revoke method. this callback can be a member of AioCompletion |
|
@yuyuyu101 Hmm -- not sure where you are going w/ this. Once we fire the AioCompletion back to the end-user (e.g. QEMU), there is an expectation that the memory buffers they provided to the read/write operation are now free for re-use by the end-user. Providing a mechanism for "revoking" the buffers doesn't solve the problem because semantically the buffers should be revoked from Ceph-usage before we fire the completion. Even if we provided a way to revoke the buffers, bufferlist doesn't have any locks to protect its ptr collection from concurrent access. |
|
Hmm, no, I mean callback is related to the bufferptr not AioCompletion. Just using AioCompletion to pass callback to bufferptr. void revoke_buffer(char *buffer) comp = create_rbd_completion(cct, revoke_buffer); |
|
@yuyuyu101 Still not understanding what you are proposing. As highlighted Sage, the bufferptr can be held for a potentially long time after the AioComlletion has completed. In the case of something like QEMU w/ virtio, this memory is coming from the ring buffer between the guest OS and QEMU. Therefore, w/o copying the memory, the only safe thing to do would be to stall the AioCompletion until Ceph is no longer referencing the memory. |
No description provided.