From: Christoph Hellwig <hch@infradead.org>
To: Shaohua Li <shli@fb.com>
Cc: linux-ide@vger.kernel.org, Kernel-team@fb.com,
dan.j.williams@intel.com, Jens Axboe <axboe@fb.com>,
Tejun Heo <tj@kernel.org>, Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH v3 3/3] libata: use blk taging
Date: Fri, 16 Jan 2015 00:23:44 -0800 [thread overview]
Message-ID: <20150116082344.GA4913@infradead.org> (raw)
In-Reply-To: <92a8da78d57926f61e9050168499872d52066f1c.1421371412.git.shli@fb.com>
> +static bool ata_valid_internal_tag(struct ata_port *ap, struct ata_device *dev,
> + unsigned int tag)
> +{
> + if (!ap->scsi_host)
> + return !test_and_set_bit(tag, &ap->sas_tag_allocated);
> + return !dev->sdev ||
> + !blk_queue_find_tag(dev->sdev->request_queue, tag);
How is this supposed to work with blk-mq?
> +}
> +
> /**
> * ata_exec_internal_sg - execute libata internal command
> * @dev: Device to which the command is sent
> @@ -1585,8 +1594,7 @@ unsigned ata_exec_internal_sg(struct ata_device *dev,
> else
> tag = 0;
>
> - if (test_and_set_bit(tag, &ap->qc_allocated))
> - BUG();
> + BUG_ON(!ata_valid_internal_tag(ap, dev, tag));
But given that this is just a single assert we might as well just
remove that whole thing.
> +static struct ata_queued_cmd *ata_qc_new(struct ata_port *ap, int blktag)
> +{
> + struct ata_queued_cmd *qc;
> +
> + /* no command while frozen */
> + if (unlikely(ap->pflags & ATA_PFLAG_FROZEN))
> + return NULL;
> +
> + /* SATA will directly use block tag. libsas need its own tag management */
> + if (ap->scsi_host) {
> + qc = __ata_qc_from_tag(ap, blktag);
> + qc->tag = blktag;
> + return qc;
> + }
> +
> + return sas_ata_qc_new(ap);
Why don't you merge tis into ata_qc_new_init?
> +static void sas_ata_qc_free(unsigned int tag, struct ata_port *ap)
> +{
> + if (!ap->scsi_host)
Given the sas_ name I'd move the check into the caller.
That beeing said I wonder if you shouldn't do all this at a much
higher level.
__ata_scsi_queuecmd has a two callers, one for sata, and one for sas.
If you pass in the tag from that level the low lever code won't
need any branches for sas vs libata. The only downside would be
that you now consume a tag for simulated command on SAS, but as that's
already done for SATA it can't be that bad.
> @@ -3666,6 +3666,8 @@ int ata_scsi_add_hosts(struct ata_host *host, struct scsi_host_template *sht)
> */
> shost->max_host_blocked = 1;
>
> + scsi_init_shared_tag_map(shost, host->n_tags);
> +
You need to check the return value here.
next prev parent reply other threads:[~2015-01-16 8:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-16 1:32 [PATCH v3 1/3] block: support different tag allocation policy Shaohua Li
2015-01-16 1:32 ` [PATCH v3 2/3] blk-mq: add " Shaohua Li
2015-01-16 1:32 ` [PATCH v3 3/3] libata: use blk taging Shaohua Li
2015-01-16 8:23 ` Christoph Hellwig [this message]
2015-01-16 22:16 ` Shaohua Li
2015-01-22 21:12 ` Shaohua Li
2015-01-23 20:13 ` Tejun Heo
2015-01-23 21:13 ` Jens Axboe
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=20150116082344.GA4913@infradead.org \
--to=hch@infradead.org \
--cc=Kernel-team@fb.com \
--cc=axboe@fb.com \
--cc=dan.j.williams@intel.com \
--cc=linux-ide@vger.kernel.org \
--cc=shli@fb.com \
--cc=tj@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.