Re: [PATCH 0/3] ata: fix deferred QC handling for port multipliers

[John Garry <john.g.garry@oracle.com>]

On 01/05/2026 19:42, Niklas Cassel wrote:
> On Fri, May 01, 2026 at 03:19:03PM +0100, John Garry wrote:
>> On 01/05/2026 13:54, Niklas Cassel wrote:
>>
>> As I understand, this deferred QC scheme was intended to solve starvation
>> problems for multiqueue SAS HBAs (using libsas-based drivers). libsas has no
>> port multiplier support, so I wonder why we make deferred QC scheme work for
>> port multiplier, i.e. non-libsas scenario.
> 
> Are you certain that there are no libsas HBAs that support port
> multipliers?

No, I am just saying that libsas does not support port multipliers, see 
earlier effort @ 
https://lore.kernel.org/linux-scsi/1398346023-10225-1-git-send-email-yxlraid@gmail.com/

See this today:

int sas_discover_sata(struct domain_device *dev)
{
	if (dev->dev_type == SAS_SATA_PM)
		return -ENODEV;

> 
> 
> Basically, before commit:
> 0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation")
> 
> We always aborted a new command, if that would have caused NCQ and non-NCQ
> commands to be mixed on the same device.
> Regardless if libsas driver or any other SATA driver, e.g. AHCI.
> 
> 
> After commit:
> 0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation")
> If sending a non-NCQ command while NCQ commands are in flight,
> we instead save the non-NCQ command and issue it as soon all NCQ
> commands are finished, from a workqueue.
> 
> This commit changed the behavior both for libsas based drivers and
> all other SATA drivers, including AHCI, which does support Port
> Multipliers.
> 
> As you might now, Port Multipliers are not that common, and I think
> simply no one tested the change on Port Multipliers before the change
> was included.
> 
> 
> As you can see in patch 2/3, we basically stop using this deferred QC
> issuing via workqueue for Port Multipliers with CBS - when sending
> commands to different devices.
> 
> For Port Multipliers with FBS support, or PMPs with CBS support where
> issuing commands within the same drive, we are still using it.
> 
> For PMPs with FBS, I don't see any problem of keep using the workqueue
> to issue a deferred QC. It should basically be the same as if directly
> connected on the port. (There is no extra logic to handle ap->excl_link.)
> 
> 
> For PMPs with CBS, we could keep the same behavior as before, and just
> abort the command, if NCQ and non-NCQ are mixed.
> 
> The advantage is that the workqueue issuing would not be able to somehow
> collide with the ap->excl_link handling for CBS PMPs. Looking at the code,
> it "should work", because we always will always have ATA_QCFLAG_CLEAR_EXCL
> set on the QC issued by the workqueue.
> 
> This would require that we know that PMPs (with CBS) can't be used on
> libsas based HBAs.

Please see above.

> Hell, we could probably do that if we wanted to, since
> I don't think that people using an expense SAS HBA with a cheap CBS PMP
> (does not not even support FBS) is very common in practice.,,

Yes, SAS has expanders for this purpose.

Thanks,
John