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
