On Wed, May 18, 2022 at 09:18:45PM +0800, Ming Lei wrote: > Hello Liu, > > On Wed, May 18, 2022 at 02:38:08AM -0400, Liu Xiaodong wrote: > > On Tue, May 17, 2022 at 01:53:57PM +0800, Ming Lei wrote: > > > Hello Guys, > > > > > > ubd driver is one kernel driver for implementing generic userspace block > > > device/driver, which delivers io request from ubd block device(/dev/ubdbN) into > > > ubd server[1] which is the userspace part of ubd for communicating > > > with ubd driver and handling specific io logic by its target module. > > > > > > Another thing ubd driver handles is to copy data between user space buffer > > > and request/bio's pages, or take zero copy if mm is ready for support it in > > > future. ubd driver doesn't handle any IO logic of the specific driver, so > > > it is small/simple, and all io logics are done by the target code in ubdserver. > > > > > > The above two are main jobs done by ubd driver. > > > > Not like UBD which is straightforward and starts from scratch, VDUSE is > > embedded in virtio framework. So its implementation is more complicated, but > > all virtio frontend utilities can be leveraged. > > When considering security/permission issues, feels UBD would be easier to > > solve them. > > Stefan Hajnoczi and I are discussing related security/permission > issues, can you share more details in your case? Hi, Ming Security/permission things covered by your discussion are more than I've considered. > > > > So my questions are: > > 1. what do you think about the purpose overlap between UBD and VDUSE? > > Sorry, I am not familiar with VDUSE, motivation of ubd is just to make one > high performance generic userspace block driver. ubd driver(kernel part) is > just responsible for communication and copying data between userspace buffers > and kernel io request pages, and the ubdsrv(userspace) target handles io > logic. > > > 2. Could UBD be implemented with SPDK friendly functionalities? (mainly about > > io data mapping, since HW devices in SPDK need to access the mapped data > > buffer. Then, in function ubdsrv.c/ubdsrv_init_io_bufs(), > > "addr = mmap(,,,,dev->cdev_fd,)", > > No, that code is actually for supporting zero copy. > > But each request's buffer is allocated by ubdsrv and definitely available for any > target, please see loop_handle_io_async() which handles IO from /dev/ubdbN about > how to use the buffer. Fro READ, the target code needs to implement READ > logic and fill data to the buffer, then the buffer will be copied to > kernel io request pages; for WRITE, the target code needs to use the buffer to handle > WRITE and the buffer has been updated with kernel io request. > Oh, I see. Yes, you are right. Mmapped addr in ubdsrv_init_io_bufs is not used yet. Request's buffer is allocated by ubdsrv. > > SPDK needs to know the PA of "addr". > > What is PA? and why? Physical address. Sorry, I forgot to expand it. Previously I've thought Request data buffer is from mmap addr on corresponding ubd cdev, then I just thought SPDK need to know the PA of the buffer for its backend hardware devices. If the request data buffer is allocated by srv process, then it was not needed. So maybe SPDK can be efficiently working on your corrent implementation. I'll try to draft an SPDK service backend later. Thanks Xiaodong
