On 06/30/2015 07:38 PM, Roland Dreier wrote:
On Tue, Jun 30, 2015 at 3:47 PM, Craig Watson
<craig.watson@xxxxxxxxxxxxxxxxxxx> wrote:
I recently ran a test on a LIO target system. I used a Windows 7 Pro box
with an ATTO card running iometer (www.iometer.org) hooked to a Linux target
running kernel 4.0.4 with a QLE-2562. Just doing a read with a 5MB transfer
size fails! I thought this was all fixed with commit
"11e764bd5ed4bb930e0ec5dd161df58307507347, 09-May-2012, Nicholas Bellinger
target: Remove max_sectors device attribute for modern se_task less code"
and maybe commit "046ba64285a4389ae5e9a7dfa253c6bff3d7c341, 07-Jan-2015,
Nicholas Bellinger target: Drop arbitrary maximum I/O size limit" (and a few
others)?
Yeah, those commits don't really make sense. The qlogic hardware
really has a limit on the number of gather/scatter entries a
descriptor can have, so given the LIO model of executing IOs in a
single chunk, there really is a size limit on commands that qla2xxx
can handle.
As far as I know, the only way to raise this limit is to implement
handling for doing partial commands. In other words, for a 30MB read,
break it up into 1MB reads and return each 1MB with a separate qla2xxx
HW descriptor.
- R.
Thanks for responding Roland.
So, is it really a limitation in the hardware? .. or is it in the
qla2xxx driver? Does the qla2xxx driver not support chained
scatter/gather lists?
Since the removal of fabric_max_sectors et.al. how is this size limit
communicated to an initiator? From what I understood, the target front
end is going to reflect the limit of the back end storage. Right now
what I (and our customers) see is just a refusal to operate at large (>
4.9MB) transfer sizes. At some write sizes there aren't even any error
indications on the target. The target just stops responding. This
isn't a good thing. It's better than crashing but not by much. Other
sizes do seem to crash the kernel which really isn't a good thing.
Craig Watson
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
