Re: [PATCH v6 31/37] sg: add sg_iosubmit_v3 and sg_ioreceive_v3 ioctls

[Douglas Gilbert <dgilbert@interlog.com>]

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.