On 04/02/2015 06:18 AM, Ilias Tsitsimpis wrote:
On Wed, Apr 01, 2015 at 12:15PM, Andy Grover wrote:
I'm not too familiar with BIDI ops, but using XDWRITEREAD as an example, I
think we could specify that req.iov[] contains Data-In initially and then
Data-Out overwrites req.iov[] (which must be sized as max(in, out)). Or, if
overwriting Data-In is best avoided, then we can size req.iov[] for both and
find where the Data-Out section starts without requiring the new field.
(As an aside note, it seems your narration has reversed the meaning
of Data-In and Data-Out buffers, but this does not affect our
discussion).
Oops, yes. I hopefully have it straight now, below :)
I am not sure I understand what you are suggesting. How can we find
where the Data-Out section starts without requiring the new field? Even
when req.iov[] is sized as max(in, out), don't we need to pass both
Data-In and Data-Out buffer lengths? Can you elaborate a bit?
The buffer lengths are already given in the CDB. Still using XDWRITEREAD
as an example (see sbc-3), the transfer length field in the cdb gives us
the size in blocks, which userspace can multiply with the block size to
get the overall buffer length. TCMU guarantees req.iov[] is equal to
that. For bidi commands if we double that to put the data-in buffer
after the data-out buffer, then walking the iovec for data_out_bytes
will give us the start of the data-in section. Not the most elegant, but
we need to balance against the rare usage (yes?) of bidi commands, and
the additional implementation work, because of the flaw I mentioned in
handling new tcmu_opcodes.
Regards -- Andy
--
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
