Re: Is there any risk to call rbd_aio_write/rbd_aio_read from multiple threads using same rbd_image_t?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Nov 2, 2021 at 7:58 AM Allen Zhu <allenzhu@xxxxxxxxxx> wrote:
>
> Hi,
>
>
>
> While calling rbd_aio_write(), different rbd_image_t for same RBD image will be handled as different client.
>
> In this case, RBD exclusive lock will significantly affect write performance.
>
> Therefore, in SPDK, only one thread (i.e, one core) will be used for one rbd image (https://review.spdk.io/gerrit/c/spdk/spdk/+/6812).
>
> This implementation can not utilize all CPU resource, especially for read IO.

Hi Allen,

This thread is ancient but I'm responding here for archive's sake.

I'm having trouble believing that a single thread isn't sufficient for
issuing I/Os using rbd_aio_read() and rbd_aio_write() against a single
image.  My understanding of this aspect of SPDK RBD bdev performance
issue has been that it ends up using the same thread to issue I/Os for
_all_ images opened by SPDK app such as nvmf.  Am I mistaken?

>
>
>
> Could we call rbd_aio_write()/rbd_aio_read() from multiple threads using same rbd_image_t? Is there any risk here? Thanks!

AFAIK using a single rbd_image_t from multiple threads should be OK
(similar to using a single rados_ioctx_t when working with librados
directly).  As far as risk, unfortunately I don't see any tests that
would spawn multiple threads on the same rbd_image_t in the upstream
test suite and I'm not aware of any well-established librbd consumer
doing that out there either.

Adding Mykola who might have some more context to keep me honest.

Thanks,

                Ilya
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx



[Index of Archives]     [CEPH Users]     [Ceph Devel]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux