On 2020-01-13 1:50 a.m., Bart Van Assche wrote:
On 2020-01-12 15:57, Douglas Gilbert wrote:
Add ioctl(SG_IOSUBMIT_V3) and ioctl(SG_IORECEIVE_V3). These ioctls
are meant to be (almost) drop-in replacements for the write()/read()
async version 3 interface. They only accept the version 3 interface.
See the webpage at: http://sg.danny.cz/sg/sg_v40.html
specifically the table in the section titled: "13 SG interface
support changes".
If sgv3 is a struct sg_io_hdr object, suitably configured, then
res = write(sg_fd, &sgv3, sizeof(sgv3));
and
res = ioctl(sg_fd, SG_IOSUBMIT_V3, &sgv3);
are equivalent. Dito for read() and ioctl(SG_IORECEIVE_V3).
The Linux kernel already supports several interfaces for submitting I/O
requests asynchronously, e.g. libaio and io_uring. Do we really need yet
another interface for submitting I/O requests? Has it been considered to
add SG I/O support to one of the existing asynchronous I/O request
interfaces?
Linux policy toward new ioctl()s has changed over the years. Where adding new
ones was once forbidden or strongly discouraged they are now preferred
over unconstrained methods such as adding new system calls or using write()
and read(). The SG_IOSUBMIT and SG_IORECEIVE ioctls have now been proposed
on several occasions by L. Torvalds as replacements for write() and read()
that together with the sg v3 interface (based on struct sg_io_hdr) predate
both libaio and io_uring. So I view these two new ioctls for the sg v3
interfaces as allowing the existing write() and read() interface to be first
deprecated, then removed with the these ioctls as drop in replacements. I view
this as more end-user friendly that just removing the write() and read() calls
as the bsg driver did (and thus removing its async interface and breaking code
that used it).
As my second stage patchset demonstrates, the superior user data handling
architecture *** of the SCSI command sets (as compared to say NVMe and ATA)
allows for major performance wins in areas such as copying and comparing
disk-to-disk operations that are not available in libaio and io_uring.
Douglas Gilbert
*** that being: do _not_ specify the details of how near end user data is
handled in the command set, leave it to lower levels. So in the case
of a disk to disk copy, the commands may come asynchronously from the
user space but there is no need for the user data to leave the kernel
level. Offloaded copies now being discussed throw the problem "over
the fence" but ultimately some system needs to do the copy, and there
is a good chance that is a Linux embedded system, especially if it has
good support for copying.
