This message is from the T13 list server.
> Deafening silence.
What does support for the feature of queueing actually achieve on the commodity
desktop/laptop that (matters more than and) can't be more easily achieved by moving
beyond the Wintel barrier of 64KiB of data/command?
> Deafening silence.
Queueing in Scsi over whatever has a long history of not being implemented in a useful
way.
> a NOP with features 0x02, and then start command X.
> X would then be guarenteed not
> to be started before the previous 12 commands had finished.
One issue in Scsi Queueing has been efficiently notifying the host when a command
finally does complete without error. If Scsi over Ide (aka Atapi) has a good way of
saying please delay til all queued commands complete, then yes that would be Goodness.
Pat LaVarre
-----Original Message-----
From: Jens Axboe [mailto:[EMAIL PROTECTED]]
Sent: Mon 4/29/2002 8:52 AM
To: [EMAIL PROTECTED]
Cc:
Subject: Re: [t13] read/write queued and tags
This message is from the T13 list server.
On Wed, Apr 24 2002, Jens Axboe wrote:
> This message is from the T13 list server.
>
>
> Hi,
>
> As you all know, there is support for queued commands in ata4 and later.
> Some IBM (Deskstar) and Western Digital (Expert) drives implement this (I
> know of no others).
>
> It works, and for a single drive on a channel, it works fairly well.
> However, there are some things missing that would be nice to have.
>
> One of these features is ordered tag support. Unfortunately there are no
> option bits left for the tags in the standard taskfile, and to enable
> this to work on both 48-bit lba and older, I had the following idea:
>
> Use the NOP command with features register used for options. There's
> already (sort of) precedence for doing something to this effect, with
> the nop auto poll suggestions.
>
> COMMAND = NOP (0x00)
> FEATURES = 0x01
> Enable Auto poll
>
> COMMAND = NOP (0x00)
> FEATURES = 0x02
> Tag barrier
>
> So it would be possible to issue, eg, 12 commands, issue a NOP with
> features 0x02, and then start command X. X would then be guarenteed not
> to be started before the previous 12 commands had finished.
>
> Comments? The above is just a quick write-up, I can make this is general
> suggestion if need be.
Deafening silence. Would folks be more interested in just an update to
the {READ,WRITE}_DMA_QUEUED_EXT commands to provide this functionality,
and just forget about chs/lba28?
Or are folks just wondering why this feature would be useful? Since and
FUA bit is being considered, then I assumed I would not have to explain
that side of it.
--
Jens Axboe
