This message is from the T13 list server.
Ok, I'll bite. Can you explain the use model for your suggestion. I may not be thinking of the same thing when you say "Ordered Tag Support". If you want to set the completion order, then switching to non-queued DMA commands would achieve the same effect. MKE. -----Original Message----- From: Jens Axboe [mailto:[EMAIL PROTECTED]] Sent: Monday, April 29, 2002 7:53 AM To: [EMAIL PROTECTED] 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
