Documentation of the API functions

[derekbit]

I am developing a userspace block device as an alternative solution to iSCSI block device in the Longhorn project. Based on preliminary performance evaluations, it appears that our userspace block device (longhorn-ublk) has the potential to improve the performance of Longhorn significantly.

It would be beneficial for the ubdsrv project to offer well-documented API documentation similar to http://libfuse.github.io/doxygen. This would provide users with a clear understanding of how to utilize the ubdsrv API, making it easier to develop customized block devices that integrate with it.

Thanks for the awesome project.

[ming1]

I am developing a userspace block device as an alternative solution to iSCSI block device in the Longhorn project. Based on preliminary performance evaluations, it appears that our userspace block device, or "ublk," has the potential to improve the performance of Longhorn significantly.

That is great!

It would be beneficial for the ubdsrv project to offer well-documented API documentation similar to http://libfuse.github.io/doxygen. This would provide users with a clear understanding of how to utilize the ubdsrv API, making it easier to develop customized block devices that integrate with it.

OK, got it. I know ublk document could be one problem for users,
and will improve it.

Thanks,
Ming

[ming1]

I am developing a userspace block device as an alternative solution to iSCSI block device in the Longhorn project. Based on preliminary performance evaluations, it appears that our userspace block device (longhorn-ublk) has the potential to improve the performance of Longhorn significantly.

It would be beneficial for the ubdsrv project to offer well-documented API documentation similar to http://libfuse.github.io/doxygen. This would provide users with a clear understanding of how to utilize the ubdsrv API, making it easier to develop customized block devices that integrate with it.

Now doxygen style documentation for libublksrv API is supported by
commit 0747711

generate html doc in doc/html/

make doxygen_doc

Please try it and see if you are fine with it.

Thanks,

[derekbit]

@ming1
Thank you! It loos good to me.

[derekbit]

I am developing a userspace block device as an alternative solution to iSCSI block device in the Longhorn project. Based on preliminary performance evaluations, it appears that our userspace block device (longhorn-ublk) has the potential to improve the performance of Longhorn significantly.

FYR, the performance improvement in Longhorn (write iops is clamped by the Longhorn's internal datapath design).
The implementation actually follows the ublk-nbd.

One question raised when I was benchmarking it. When I increase the queue_depth to 63, the seq write iops decreases. Do you have any idea?

[ming1]

I am developing a userspace block device as an alternative solution to iSCSI block device in the Longhorn project. Based on preliminary performance evaluations, it appears that our userspace block device (longhorn-ublk) has the potential to improve the performance of Longhorn significantly.

FYR, the performance improvement in Longhorn (write iops is clamped by the Longhorn's internal datapath design). The implementation actually follows the ublk-nbd.

cool! Nice job!

BTW, recently I am working on zero copy support, feel free to test it
and see if it improves bw for longhorn-ublk if you are interested in it:

https://lore.kernel.org/linux-block/ZBKTUtWTVdcTeUHD@ovpn-8-22.pek2.redhat.com/T/#m3427c77c10a49ad99f40354f9c4aeabcc5bf27cd

One question raised when I was benchmarking it. When I increase the queue_depth to 63, the seq write iops decreases. Do you have any idea?

1. What is your ethernet link?

• the bw of 1496821KiB/sec is ~11Gbps
• I don't have such switch at hand

2. what is the iops or bw difference between 63 qd and 31 qd?

3. can you observe similar iops decrease on ublk-nbd after switching ot 63 qd from 31 qd? I can't observe such difference when running ublk-nbd inside
   my VM, which is over local tcp socket.

Also io_uring handles 'tcp send' one by one by IO_LINK, and increasing
qd could just make the whole tcp send chain becoming longer. I feel it
is related with io_uring implementation, and shouldn't be related with
net.

BTW, I am not familiar with iscsi protocol, so can't guess how iscsi
is implemented by io_uring.

Also just be curious, why don't you write one nvme-tcp over ublk,
which is supposed to be more fast than iscsi.

Thanks,
Ming