Messages in this thread | | | Date | Mon, 13 Jun 2022 10:34:41 +0100 | Subject | Re: [PATCH RFC v2 03/18] scsi: core: Implement reserved command handling | From | John Garry <> |
| |
On 13/06/2022 10:06, Damien Le Moal wrote: >>> We cannot have more than 32 tags. >> We may have 32 regular tags and 1 reserved tag for SATA. > Right. But that is the messy part though. That extra 1 tag is actually not > a tag since all internal commands are non-NCQ commands that do not need a > tag...
But apart from SATA, libsas LLDDs do need a real tag for the libata internal command.
> > I am working on command duration limits support currently. This feature > set has a new horrendous "improvement": a command can be aborted by the > device if it fails its duration limit, but the abort is done with a good > status + sense data available bit set so that the device queue is not > aborted entirely like with a regular NCQ command error. > > For such aborted commands, the command sense data is set to > "COMPLETED/DATA UNAVAILABLE". In this case, the host needs to go read the > new "successful NCQ sense data log" to check that the command sense is > indeed "COMPLETED/DATA UNAVAILABLE". And to go read that log page without > stalling the device queue, we would need an internal NCQ (queuable) command. > > Currently, that is not possible to do cleanly as there are no guarantees > we can get a free tag (there is a race between block layer tag allocation > and libata internal tag counting). So a reserved tag for that would be > nice. We would end up with 31 IO tags at most + 1 reserved tag for NCQ > commands + ATA_TAG_INTERNAL for non-NCQ. That last one would be rendered > rather useless. But that also means that we kind-of go back to the days > when Linux showed ATA drives max QD of 31...
So must the ATA_TAG_INTERNAL qc always be available for non-NCQ action like EH, and that is why you cannot reuse for this internal NCQ (queuable) command?
> > I am still struggling with this particular use case and trying to make it > fit with your series. Trying out different things right now. >
ok
> >>> I think keeping can_queue as the max queue depth with at most >>> nr_reserved_cmds tags reserved is better. >> Maybe the wording in the comment can be improved as it originally >> focused on SAS HBAs where there are no special rules for tagset depth or >> how the tagset should be carved up to handle regular and reserved commands. > Indeed. And that would be for HBAs that do*not* use libsas/libata. > Otherwise, the NCQ vs non-NCQ reserved tag mess is there. >
Thanks, John
| |