From mboxrd@z Thu Jan 1 00:00:00 1970 From: axboe@kernel.dk (Jens Axboe) Date: Thu, 16 Jul 2015 10:49:54 -0600 Subject: [PATCH 1/3] block: copy multi iovec user mappings if QUEUE_FLAG_SG_GAPS is set In-Reply-To: References: <1436966356-8979-1-git-send-email-sagig@mellanox.com> <1436966356-8979-2-git-send-email-sagig@mellanox.com> Message-ID: <55A7E0B2.900@kernel.dk> 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