splitting iovecs to bios
Konstantin Belousov
kostikbel at gmail.com
Tue Dec 22 09:51:39 UTC 2015
On Tue, Dec 22, 2015 at 11:37:23AM +0200, Max Gurtovoy wrote:
> Hi Konstantin,
>
> >
> >> There might be indeed a reason, it could be that some drivers expect
> >> blocking to be done by the userspace. The drivers could have some
> >> restrictions on transfer sizes and atomicity of transfer, which would
> >> be broken by the unconditional merge. I cannot give you an example
> >> of such driver, known block-aware drivers like sa(4) only require the
> >> bio size to be multiple of the basic block size.
> >
> > I'm surprised to learn that the generic access layer splits IO requests
> > just because some block drivers cannot handle it. I'd expect that this
> > sort of limitation would be communicated by the drivers in the form of
> > device flag SI_NOMERGE.
> >
> >> OTOH, I see no issue with adding a SI_PHYSIOMERGE flag and doing the
> >> merges for the driver in physio(), when unmapped request has consequtive
> >> iov elements ending and starting at the page boundary.
> >
> > I'd say it should be the other way around, physio would always strive
> > to append/merge iov elements but wouldn't in case the device does not
> > support it. Moreover, some modern devices does not even require the page
> > boundary alignment you mentioned. These devices can execute IO to/from
> > any arbitrary scatter list of buffers.
>
> Do you know if this issue is on someone's plate ?
> If it doesn't, maybe we can try to advance it and start implementing
> some solutions.
> As I said earlier and as Sagi mentioned, this feature can improve the
> performance of modern devices.
Sure, feel free to implement it. If you need a help, just ask.
More information about the freebsd-scsi
mailing list