Re: [ceph-users] Any librados C API users out there?

2017-01-12 Thread Matt Benjamin
otr Dałek" > <piotr.da...@corp.ovh.com>, "ceph-devel" <ceph-de...@vger.kernel.org>, > "ceph-users" <ceph-users@lists.ceph.com> > Sent: Thursday, January 12, 2017 3:22:06 PM > Subject: Re: [ceph-users] Any librados C API users out there? >

Re: [ceph-users] Any librados C API users out there?

2017-01-12 Thread Sage Weil
On Thu, 12 Jan 2017, Yehuda Sadeh-Weinraub wrote: > On Thu, Jan 12, 2017 at 12:08 PM, Sage Weil wrote: > > On Thu, 12 Jan 2017, Gregory Farnum wrote: > >> On Thu, Jan 12, 2017 at 5:54 AM, Jason Dillaman > >> wrote: > >> > There is option (3) which is to

Re: [ceph-users] Any librados C API users out there?

2017-01-12 Thread Sage Weil
On Thu, 12 Jan 2017, Gregory Farnum wrote: > On Thu, Jan 12, 2017 at 5:54 AM, Jason Dillaman wrote: > > There is option (3) which is to have a new (or modified) > > "buffer::create_static" take an optional callback to invoke when the > > buffer::raw object is destructed. The

Re: [ceph-users] Any librados C API users out there?

2017-01-12 Thread Gregory Farnum
On Thu, Jan 12, 2017 at 5:54 AM, Jason Dillaman wrote: > There is option (3) which is to have a new (or modified) > "buffer::create_static" take an optional callback to invoke when the > buffer::raw object is destructed. The raw pointer would be destructed > when the last

Re: [ceph-users] Any librados C API users out there?

2017-01-12 Thread Jason Dillaman
There is option (3) which is to have a new (or modified) "buffer::create_static" take an optional callback to invoke when the buffer::raw object is destructed. The raw pointer would be destructed when the last buffer::ptr / buffer::list containing it is destructed, so you know it's no longer being

Re: [ceph-users] Any librados C API users out there?

2017-01-12 Thread Sage Weil
On Thu, 12 Jan 2017, Piotr Dałek wrote: > On 01/11/2017 07:01 PM, Sage Weil wrote: > > On Wed, 11 Jan 2017, Jason Dillaman wrote: > > > On Wed, Jan 11, 2017 at 11:44 AM, Piotr Dałek > > > wrote: > > > > As the subject says - are here any users/consumers of librados C

Re: [ceph-users] Any librados C API users out there?

2017-01-11 Thread Jason Dillaman
On Wed, Jan 11, 2017 at 1:01 PM, Sage Weil wrote: > Jason, where does librbd fall? Option (2) won't help for users like QEMU unless we can tie the reference counting back into the AioCompletion (i.e. delay firing until all references to the memory are released). -- Jason

Re: [ceph-users] Any librados C API users out there?

2017-01-11 Thread Sage Weil
On Wed, 11 Jan 2017, Jason Dillaman wrote: > +1 > > I'd be happy to tweak the internals of librbd to support pass-through > of C buffers all the way to librados. librbd clients like QEMU use the > C API and this currently results in several extra copies (in librbd > and librados). +1 from me

Re: [ceph-users] Any librados C API users out there?

2017-01-11 Thread Jason Dillaman
It does internally -- which requires the extra copy from C array to a bufferlist. I had a PR for wrapping the C array into a bufferlist (w/o the copy), but Sage pointed out a potential issue with such implementations (which might still be an issue w/ this PR). [1]

Re: [ceph-users] Any librados C API users out there?

2017-01-11 Thread Samuel Just
Jason: librbd itself uses the librados C++ api though, right? -Sam On Wed, Jan 11, 2017 at 9:37 AM, Jason Dillaman wrote: > +1 > > I'd be happy to tweak the internals of librbd to support pass-through > of C buffers all the way to librados. librbd clients like QEMU use the >

Re: [ceph-users] Any librados C API users out there?

2017-01-11 Thread Jason Dillaman
+1 I'd be happy to tweak the internals of librbd to support pass-through of C buffers all the way to librados. librbd clients like QEMU use the C API and this currently results in several extra copies (in librbd and librados). On Wed, Jan 11, 2017 at 11:44 AM, Piotr Dałek

[ceph-users] Any librados C API users out there?

2017-01-11 Thread Piotr Dałek
Hello, As the subject says - are here any users/consumers of librados C API? I'm asking because we're researching if this PR: https://github.com/ceph/ceph/pull/12216 will be actually beneficial for larger group of users. This PR adds a bunch of new APIs that perform object writes without