Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 22 Dec 2015 11:51:31 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Max Gurtovoy <maxg@mellanox.com>
Cc:        Sagi Grimberg <sagig@dev.mellanox.co.il>, Sagi Grimberg <sagig@mellanox.com>, freebsd-scsi@freebsd.org, Hans Petter Selasky <hanss@mellanox.com>, Oren Duer <oren@mellanox.com>
Subject:   Re: splitting iovecs to bios
Message-ID:  <20151222095131.GJ3625@kib.kiev.ua>
In-Reply-To: <567919D3.6050004@mellanox.com>
References:  <56696E03.8050202@mellanox.com> <20151210150210.GY82577@kib.kiev.ua> <566D2C91.9050900@dev.mellanox.co.il> <567919D3.6050004@mellanox.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151222095131.GJ3625>