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

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



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