On Fri, Aug 02, 2002 at 08:48:06AM -0500, James Bottomley wrote:
> The SCSI changes (small that they are) look reasonable.
>
> This does look like it exposes an existing problem in the tag/barrier
> approach, though.
>
> The bio can be split by making multiple requests over segements of the bio,
> correct? If this is a BIO_RW_BARRIER, then each of these requests will be a
It doesn't quite go as far as multiple requests in the full sense
of what a struct request represents.
All it allows at the moment is the ability for a driver to setup
a command that involves multiple sequential transfers to complete
a single request where each transfer covers a chunk of data for
a portion of the request. Variations like:
setup command
process_that_request_first - chunk 1
[interrupt, status check]
end_that_request_first - chunk1
process_that_request_first - chunk 2
[interrupt, status check]
end_that_request_first - chunk 2
or
setup command
process_that_request_first - chunk 1
process_that_request_first - chunk 2
process_that_request_first - chunk 3
..
end_that_request_first - chunk 1 + 2 + 3
There is only one call to ->request_fn for the entire request, and
the drivers manages things underneath. The chunks are expected to
complete sequentially. In the situation where the request is
restarted in the event of an error (say), the submission pointers
are rolled back to the last (successfully) completed point
before issuing the request again.
Right now I do not know what kind of use there could be for this
in the context of SCSI in general (in IDE, as I had mentioned
before, PIO commands, especially multi-count writes follow such
a pattern). You would probably be in a better position to
do so, and suggestions to improve this in that regard are very
welcome indeed. Which is why it is harder for me to decide if the
situation you suggest could arise with SCSI, since its not clear
whether such pieces/sub-requests are generated in that case.
</ramble>
I must say that I initially did think that this could be
extended to the more generic case which you probably are
referring to and that such an approach could take away the need
to split bios in certain cases (i.e. when the i/o is destined for
a single queue). Later it appeared that trying to cover
the case where each of these pieces gets queued up and might
complete out of order (requiring a tag to correlate things on
completion), would most likely boil down to trying to maintain
all the state that struct request does today.
You might recall the discussion with Niels at the kernel
summit about the alternate possibility of having two request
structs pointing to the same bio, now that we track submission
state separately. In this case, though, as completion state is
still indicated in the bio, it could get a little inelegant
to handle in the context of remembering partial completion
state for two requests simultaneously. Whether partial
completion at a granularity of less than one bio makes sense,
however, is another question that discussions with
Barthlomiej has brought up.
At the same time, if we can afford to allocate a fresh
request struct, then probably allocating a bio (possibly from
a pool associated with the queue) may not sound all that bad.
</ramble>
> REQ_BARRIER. However, in the SCSI paradigm where we translate REQ_BARRIER to
> ordered tag, each of the requests will get a new ordered tag as it comes back
> around through end_that_request_first, potentially allowing other tags to be
> inserted in between these, which would be incorrect, since other bios would be
> inserted in between the segments of this one, thus violating the barrier.
>
> Is the above correct? If it is, I may have finally found a use for linked
> scsi tasks (gives you the ability to have one tag cover multiple commands).
Would be nice (for me) to understand this in more detail.
There might be some possibilities.
Any pointers that I can look up to get a clearer idea ?
Does completion notification happen only when all the commands
covered by a single tag complete ? Otherwise, what is the ordering
amongst the multiple commands in question (do they complete in
serial order as well) ?
Regards
Suparna
>
> James
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:27 EST