[lkml]   [2002]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Bio Traversal Changes
    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


    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.

    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.

    > 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) ?


    > James
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:27    [W:0.028 / U:11.392 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site