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

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

 



On 01/15/2015 11:59 AM, Dan Williams wrote:
On Thu, Jan 15, 2015 at 10:40 AM, Shaohua Li <shli@xxxxxx> 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

--
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



[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