[PATCH 1/3] block: copy multi iovec user mappings if QUEUE_FLAG_SG_GAPS is set

[Jens Axboe]

On 07/16/2015 10:47 AM, Keith Busch wrote:
> On Wed, 15 Jul 2015, Sagi Grimberg wrote:
>> For drivers that don't support gaps in the SG lists handed to them we
>> must
>> not create bios from multiple iovecs as they can be (and usually are)
>> discontiguous.  This doesn't matter for any current user, but will help
>> to allow iSER which can't handle gaps to use the QUEUE_FLAG_SG_GAPS flag
>> instead of using driver-local bounce buffering.
>
> Maybe SG_GAPS is a bit of a misnomer. There are cases we can directly
> map a user iov with multiple discontiguous vectors. At least for NVMe
> it'd work if each iov's base and length are on page boundaries, we don't
> need to do the indirect copy.
>
> Like with this user example:
> ---
>      int fd = open("/dev/nvme0n1", O_RDONLY | O_DIRECT);
>      struct iovec iov[2];
>       unsigned char *buffer;
>
>       posix_memalign((void **)&buffer, 0x4000, 0x1000);
>
>       iov[0].iov_base = &buffer[0];
>       iov[1].iov_base = &buffer[0x2000];
>       iov[0].iov_len = 0x1000;
>       iov[1].iov_len = 0x1000;
>
>      readv(fd, iov, 2);

SG_GAPS is a bit of a misnomer, but it's not easy to explain exactly 
what that logic is in a few short words! SG gaps was the closest I could 
come up with.

-- 
Jens Axboe