On Thu, 2013-07-25 at 20:09 -0600, Jens Axboe wrote: > On Thu, Jul 25 2013, Nicholas A. Bellinger wrote: > > On Thu, 2013-07-25 at 12:16 +0200, Alexander Gordeev wrote: > > > On Mon, Jul 22, 2013 at 02:10:36PM -0700, Nicholas A. Bellinger wrote: > > > > Np. FYI, you'll want to use the latest commit e7827b351 HEAD from > > > > target-pending/scsi-mq, which now has functioning scsi-generic support. > > > > > > Survives a boot, a kernel build and the build's result :) > > > > Great. Thanks for the feedback Alexander! > > > > So the next step on my end is to enable -mq for ahci, and verify initial > > correctness using QEMU/KVM hardware emulation. > > > > Btw, I've been looking at enabling the SHT->cmd_size for struct > > ata_queued_cmd descriptor pre-allocation, but AFAICT these descriptors > > are already all pre-allocated by libata and obtained via ata_qc_new() -> > > __ata_qc_from_tag() during ata_scsi_queuecmd(). > > Might still not be a bad idea to do it: > > - Cleans up a driver, getting rid of the need to alloc, maintain, and > free those structures. > > - Should be some cache locality benefits to having it all sequential. > Looking at this some more, there are a number of locations outside of the main blk_mq_ops->queue_rq() -> SHT->queuecommand_mq() dispatch that use *ata_qc_from_tag() to obtain *ata_queued_cmd, and a few without a associated struct scsi_cmnd like libata-core.c:ata_exec_internal_sg() for example.. So I don't think (completely) getting rid of ata_port->qcmds[] will be possible, and just converting the ata_scsi_queuecmd() path to use the extra SHT->cmd_size pre-allocation for *ata_queued_cmd might end up being more trouble that it's worth. Still undecided on that part.. Tejun, do you have any thoughts + input here..? --nab -- 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
