Re: [PATCH v2 3/3] libata: use blk taging

[Jens Axboe <axboe@fb.com>]

On 01/15/2015 11:59 AM, Dan Williams wrote:
> On Thu, Jan 15, 2015 at 10:40 AM, Shaohua Li <shli@fb.com> wrote:
>> 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.
>
> I still don't understand what we get by adding this new allocator
> besides complexity, am I missing something?

Two things:

- libata tag allocator sucks. Like seriously sucks, it's almost a worst 
case implementation.
- Much better to have a single unified allocator to tweak and tune, than 
having separate version.

#2 is still lacking a bit, but I don't think it'd be impossible to unify 
it all.

-- 
Jens Axboe