On Thu, Jan 15, 2015 at 01:28:36AM -0800, Christoph Hellwig wrote: > On Wed, Jan 14, 2015 at 09:37:30AM -0800, Dan Williams wrote: > > libsas uses the libata allocated tag for NCQ. libsas first asks > > libata to allocate a tag/qc for ncq, then it creates a sas_task and > > assigns the scsi tag. To use a generic allocator I assume you would > > need to flip that ordering to allocate the sas_task tag first and then > > use that plus another key to allocate a sub-tag for ata to use for > > NCQ. > > As far as I can tell all libsas drivers as well as ipr use block > layer tagging, so they always get requests/scsi_cmnds with a tag > already assigned. For libsas drivers currently use per-LUN tags, > although with scsi-mq we will get per-host tags. > > libata on the other hand at the moment assigns it's own tags, > which are only stored in struct ata_queued_cmd, but never in the > request. libata assigns tags per ata_host. Each ata_host > might have multiple ports, which each get their own Scsi_Host > allocated. > > Given that ATA NCQ has a fairly low queue depth I assume we want > to stick to assigning ATA tags per-device, but due to the host > per device scheme libata that even works using scsi-mq. (Q: how do tags > work when port mulipliers are involved?) > > So for SAS driver using libata we will need a separate tag allocator, > but that one might as well be in libsas instead of keeping it in libata. Yep, the ATA NCQ should work well with block tag as each port is a scsi host. So looks it's not easy to map scsi tag to ATA tag for libsas and we eventually will have another tag allocator for libsas. Tejun, I'm afraid I can't work out a patch to delete the old tag allocator for libata. Can we take this patch series first and later we can delete the old tag allocator till libsas has its own tag allocator. This isn't optimal, but I really know nothing about libsas. Thanks, Shaohua -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
