Re: [PATCH RFC v2 03/18] scsi: core: Implement reserved command handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux