From: John Garry <john.garry@huawei.com>
To: Damien Le Moal <damien.lemoal@opensource.wdc.com>,
Hannes Reinecke <hare@suse.de>, <jejb@linux.ibm.com>,
<martin.petersen@oracle.com>, <bvanassche@acm.org>, <hch@lst.de>,
<ming.lei@redhat.com>, <niklas.cassel@wdc.com>
Cc: <axboe@kernel.dk>, <jinpu.wang@cloud.ionos.com>,
<linux-block@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-ide@vger.kernel.org>, <linux-scsi@vger.kernel.org>,
<linuxarm@huawei.com>, <john.garry2@mail.dcu.ie>
Subject: Re: [PATCH RFC v3 2/7] ata: libata-scsi: Add ata_internal_queuecommand()
Date: Fri, 28 Oct 2022 09:14:24 +0100 [thread overview]
Message-ID: <a3fe8284-d002-36b0-7e09-67f132353088@huawei.com> (raw)
In-Reply-To: <07028dac-d6cc-d707-db08-b92c365a6220@opensource.wdc.com>
On 27/10/2022 23:35, Damien Le Moal wrote:
>> At what stage do you want to send these commands? The tags for the shost
>> are not setup until scsi_add_host() -> scsi_mq_setup_tags() is called,
>> so can't expect blk-mq to manage reserved tags before then.
>>
>> If you are required to send commands prior to scsi_add_host(), then I
>> suppose the low-level driver still needs to manage tags until the shost
>> is ready. I guess that some very simple scheme can be used, like always
>> use tag 0, since most probe is done serially per-host. But that's not a
>> case which I have had to deal with yet.
> In libata case, ata_dev_configure() will cause a lot of
> ata_exec_internal_sg() calls for IDENTIFY and various READ LOG commands.
> That is all done with non-ncq commands, which means that we do not require
> a hw tag. But given that you are changing ata_exec_internal_sg() to call
> alloc_request + blk_execute_rq_nowait(), how would these work without a
> tag, at least a soft one ? Or we would need to keep the current code to
> use ata_qc_issue() directly for probe time ? That will look very ugly...
>
I am not sure if there is really a problem. So libata/libsas allocs the
shost quite early, and that is before we try using
ata_exec_internal_sg(). Also note that I added patch "ata: libata-scsi:
Allocate sdev early in port probe" so that we have ata_device.sdev ready
before issuing ata_exec_internal_sg() (sorry if I'm stating the obvious).
I think Hannes' issue is that some SCSI HBA driver needs to send
"internal" commands to probe the HW for info, and this would be before
shost is ready. He can tell us more.
Thanks,
John
next prev parent reply other threads:[~2022-10-28 8:14 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-25 10:32 [PATCH RFC v3 0/7] blk-mq/libata/scsi: SCSI driver tagging improvements Part II John Garry
2022-10-25 10:32 ` [PATCH RFC v3 1/7] ata: libata-scsi: Add ata_scsi_queue_internal() John Garry
2022-10-27 1:42 ` Damien Le Moal
2022-10-27 10:45 ` John Garry
2022-10-27 22:24 ` Damien Le Moal
2022-10-25 10:32 ` [PATCH RFC v3 2/7] ata: libata-scsi: Add ata_internal_queuecommand() John Garry
2022-10-27 1:45 ` Damien Le Moal
2022-10-27 9:56 ` John Garry
2022-10-27 13:02 ` Hannes Reinecke
2022-10-27 17:23 ` John Garry
2022-10-27 22:35 ` Damien Le Moal
2022-10-28 8:14 ` John Garry [this message]
2022-10-28 8:26 ` Damien Le Moal
2022-10-27 22:25 ` Damien Le Moal
2022-10-28 8:01 ` John Garry
2022-10-28 8:07 ` Damien Le Moal
2022-10-28 8:33 ` John Garry
2022-10-31 5:59 ` Damien Le Moal
2022-11-02 9:52 ` John Garry
2022-11-02 10:07 ` Damien Le Moal
2022-11-02 11:12 ` Hannes Reinecke
2022-11-02 11:25 ` Damien Le Moal
2022-11-07 10:12 ` Hannes Reinecke
2022-11-07 13:29 ` Damien Le Moal
2022-11-07 14:34 ` Hannes Reinecke
2022-10-25 10:32 ` [PATCH RFC v3 3/7] ata: libata: Make space for ATA queue command in scmd payload John Garry
2022-10-25 10:32 ` [PATCH RFC v3 4/7] ata: libata: Add ata_internal_timeout() John Garry
2022-10-25 10:32 ` [PATCH RFC v3 5/7] ata: libata: Queue ATA internal commands as requests John Garry
2022-10-25 10:32 ` [PATCH RFC v3 6/7] scsi: mvsas: Remove internal tag handling John Garry
2022-10-25 10:32 ` [PATCH RFC v3 7/7] scsi: hisi_sas: Remove internal tag handling for reserved commands John Garry
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a3fe8284-d002-36b0-7e09-67f132353088@huawei.com \
--to=john.garry@huawei.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=damien.lemoal@opensource.wdc.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=jejb@linux.ibm.com \
--cc=jinpu.wang@cloud.ionos.com \
--cc=john.garry2@mail.dcu.ie \
--cc=linux-block@vger.kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=martin.petersen@oracle.com \
--cc=ming.lei@redhat.com \
--cc=niklas.cassel@wdc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox