From: Jens Axboe <axboe@suse.de>
To: "Peter T. Breuer" <ptb@it.uc3m.es>
Cc: linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: tagged block requests
Date: Tue, 17 Sep 2002 07:54:40 +0200 [thread overview]
Message-ID: <20020917055440.GG3289@suse.de> (raw)
In-Reply-To: <200209162234.g8GMY2825694@oboe.it.uc3m.es>
On Tue, Sep 17 2002, Peter T. Breuer wrote:
> Can someone point me to some documentation or an example
> or give me a quick rundown on how I should use the new
> tagged block request structure in 2.5.3x?
>
> It looks like something I want. I've already tried issuing
> "special" requests as (re)ordering barriers, and that works
> fine. How does the tag request interface fit in with that,
> if it does?
The request tagging is used for hardware that can have multiple commands
in flight at any point in time. To do this, we need some sort of cookie
to differentiate between the different commands. For SCSI and IDE, we
use integer tags to do so. An example:
my_request_fn(q)
{
struct request *rq;
next:
rq = elv_next_request(q);
if (!rq)
return;
/*
* assuming some tags are already in flight, ending those will
* restart queue handling
*/
if (blk_queue_start_tag(q, rq))
return;
/*
* now rq is tagged, rq->tag contains the integer identifier
* for this request
*/
dma_map_command();
send_command_to_hw();
goto next;
}
So request_fn calls blk_queue_start_tag(), which associates rq with a
free tag, if available. Then the hardware completes the request:
my_isr(..., devid, ...)
{
struct my_dev *dev = devid;
struct request *rq;
int stat, tag;
stat = read_device_stat(dev);
/* tag is upper 5 bits */
tag = (stat >> 3);
rq = blk_queue_find_tag(q, tag);
if (stat & DEVICE_GOOD_STAT) {
blk_queue_end_tag(q, rq);
complete_request(rq, 1);
} else {
blk_queue_invalidate_tags(q);
lock_queue;
my_request_fn(&dev->queue);
unlock_queue;
}
}
Tag is either completed normally (blk_queue_end_tag()) for good status,
and is ended. Or for bad status, we invalidate the entire pending tag
queue because this particular piece of hardware requires us to do so.
This makes sure that requests gets moved from the tag queue to the
dispatch queue for the device again, so request_fn() gets a chance to
start them over.
That's basically the API. In addition to the above,
blk_queue_init_tags(q, depth) sets up a queue for tagged operation and
blk_queue_free_tags(q) tears it down again.
Now how that fits in with whatever you are trying to do (which
apparently isn't tagging in the ordinary sense), I have no idea. But now
you should now what the interface does.
--
Jens Axboe
next prev parent reply other threads:[~2002-09-17 5:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-16 22:34 tagged block requests Peter T. Breuer
2002-09-17 5:54 ` Jens Axboe [this message]
2002-09-17 8:09 ` Andre Hedrick
2002-09-17 12:29 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020917055440.GG3289@suse.de \
--to=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=ptb@it.uc3m.es \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox