All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Bart Van Assche <bvanassche@acm.org>, Ming Lei <ming.lei@canonical.com>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	linux-rdma <linux-rdma@vger.kernel.org>,
	Christoph Hellwig <hch@infradead.org>,
	Robert Elliott <Elliott@hp.com>
Subject: Re: [PATCH 8/8] IB/srp: Add multichannel support
Date: Wed, 01 Oct 2014 10:54:28 -0600	[thread overview]
Message-ID: <542C31C4.1020702@kernel.dk> (raw)
In-Reply-To: <542C270B.5020002@acm.org>

On 2014-10-01 10:08, Bart Van Assche wrote:
> On 09/19/14 17:38, Jens Axboe wrote:
>> ctx was meant to be private, unfortunately it's leaked a bit into other
>> parts of block/. But it's still private within that, at least.
>>
>> Lets not add more stuff to struct request, it's already way too large.
>> We could add an exported
>>
>> struct blk_mq_hw_ctx *blk_mq_request_to_hctx(struct request *rq)
>> {
>> 	struct request_queue *q = rq->q;
>>
>> 	return q->mq_ops->map_queue(q, rq->mq_ctx->cpu);
>> }
>>
>> for this.
>
> How about the patch below ? That patch makes it easy for SCSI LLDs to obtain
> the hardware context index.
>
> [PATCH] blk-mq: Add blk_get_mq_tag()
>
> The queuecommand() callback functions in SCSI low-level drivers
> must know which hardware context has been selected by the block
> layer. Since passing the hctx pointer directly to the queuecommand
> callback function would require modification of all SCSI LLDs,
> add a function to the block layer that allows to query the hardware
> context index.
>
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> ---
>   block/blk-mq-tag.c     | 24 ++++++++++++++++++++++++
>   include/linux/blk-mq.h | 16 ++++++++++++++++
>   2 files changed, 40 insertions(+)
>
> diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
> index c1b9242..5618759 100644
> --- a/block/blk-mq-tag.c
> +++ b/block/blk-mq-tag.c
> @@ -595,6 +595,30 @@ int blk_mq_tag_update_depth(struct blk_mq_tags *tags, unsigned int tdepth)
>   	return 0;
>   }
>
> +/**
> + * blk_get_mq_tag() - return a tag that is unique queue-wide
> + *
> + * The tag field in struct request is unique per hardware queue but not
> + * queue-wide. Hence this function. It is not only safe to use this function
> + * for multiqueue request queues but also for single-queue request queues.
> + * Note: rq->tag == -1 if tagging is not enabled for single-queue request
> + * queues.
> + */
> +struct blk_mq_tag blk_get_mq_tag(struct request *rq)
> +{
> +	struct request_queue *q = rq->q;
> +	struct blk_mq_tag tag = { rq->tag & ((1 << 16) - 1) };
> +	struct blk_mq_hw_ctx *hctx;
> +
> +	if (q->mq_ops) {
> +		hctx = q->mq_ops->map_queue(q, rq->mq_ctx->cpu);
> +		tag.tag |= hctx->queue_num << 16;
> +	}
> +
> +	return tag;
> +}
> +EXPORT_SYMBOL(blk_get_mq_tag);

Lets get rid of the blk_mq_tag struct and just have it be an u32 or 
something. We could potentially typedef it, but I'd prefer to just have 
it be an unsigned 32-bit int.

Probably also need some init time safety checks that 16-bits is enough 
to hold BLK_MQ_MAX_DEPTH. Just in case that is ever bumped, or the queue 
prefixing changes.

And I think we need to name this better. Your comment correctly 
describes that this generates a unique tag queue wide, but the name of 
the function implies that we just return the request tag. Most drivers 
wont use this. Perhaps add a queue flag that tells us that we should 
generate these tags and have it setup ala:

u32 blk_mq_unique_rq_tag(struct request *rq)
{
	struct request_queue *q = rq->q;
	u32 tag = rq->tag & ((1 << 16) - 1);
	struct blk_mq_hw_ctx *hctx;

	hctx = q->mq_ops->map_queue(q, rq->mq_ctx->cpu);	
	return tag | (hctx->queue_num << 16);
}

u32 blk_mq_rq_tag(struct request *rq)
{
	struct request_queue *q = rq->q;

	if (q->mq_ops &&
	    test_bit(QUEUE_FLAG_UNIQUE_TAGS, &q->queue_flags))
		return blk_mq_unique_rq_tag(rq);

	return rq->tag;
}

Totally untested, just typed in email.

-- 
Jens Axboe


  reply	other threads:[~2014-10-01 16:54 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-19 12:55 [PATCH RFC 0/8] IB/srp: Add multichannel support Bart Van Assche
2014-09-19 12:56 ` Bart Van Assche
2014-09-19 18:02   ` Sagi Grimberg
2014-09-19 12:57 ` [PATCH 2/8] scsi-mq: Add support for multiple hardware queues Bart Van Assche
     [not found]   ` <541C281E.9090206-HInyCGIudOg@public.gmane.org>
2014-09-19 18:05     ` Sagi Grimberg
2014-09-19 18:11       ` Christoph Hellwig
     [not found]       ` <CAF9gx6JfP2bGyMauB6LzepZP_vKEvrd-sPZc5CRuOrtgQ_UCSw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-09-26 11:08         ` Ming Lei
     [not found]           ` <CACVXFVMiYsW=dszQ6mE-o_L8fEDdkO59vJ5qeHKch5c33K_QXw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-09-26 14:02             ` Bart Van Assche
2014-09-19 12:57 ` [PATCH 3/8] scsi-mq: Pass hctx to low-level SCSI drivers Bart Van Assche
     [not found] ` <541C27BF.6070609-HInyCGIudOg@public.gmane.org>
2014-09-19 12:58   ` [PATCH 4/8] IB/srp: Move ib_destroy_cm_id() call into srp_free_ch_ib() Bart Van Assche
     [not found]     ` <541C285B.5010309-HInyCGIudOg@public.gmane.org>
2014-09-19 18:10       ` Sagi Grimberg
2014-09-19 12:58   ` [PATCH 5/8] IB/srp: Remove stale connection retry mechanism Bart Van Assche
2014-09-19 18:25     ` Sagi Grimberg
     [not found]     ` <541C287D.1050900-HInyCGIudOg@public.gmane.org>
2014-09-20 17:45       ` Or Gerlitz
     [not found]         ` <CAJ3xEMhPKiut4MwZH9F7-T0+u7B6XPuh-FTZpA=Xe4ViAj5UUQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-10-02 10:34           ` Bart Van Assche
     [not found]             ` <542D2A3C.2080009-HInyCGIudOg@public.gmane.org>
2014-10-03  8:51               ` Bart Van Assche
2014-09-19 13:00   ` [PATCH 8/8] IB/srp: Add multichannel support Bart Van Assche
     [not found]     ` <541C28E0.7010705-HInyCGIudOg@public.gmane.org>
2014-09-19 14:28       ` Ming Lei
     [not found]         ` <CACVXFVPzz37J-613NZCfPStUBxf0rLOtz71LJ07PpCxYg5nn+g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-09-19 15:21           ` Bart Van Assche
     [not found]             ` <541C49EC.6030404-HInyCGIudOg@public.gmane.org>
2014-09-19 15:27               ` Ming Lei
2014-09-19 15:35                 ` Bart Van Assche
2014-09-19 15:38                   ` Jens Axboe
2014-09-19 17:30                     ` Sagi Grimberg
2014-09-19 17:33                       ` Jens Axboe
2014-09-19 18:11                         ` Christoph Hellwig
     [not found]                     ` <541C4DF1.4090604-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>
2014-10-01 16:08                       ` Bart Van Assche
2014-10-01 16:54                         ` Jens Axboe [this message]
2014-10-01 21:14                           ` Christoph Hellwig
     [not found]                           ` <542C31C4.1020702-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>
2014-10-02 16:45                             ` Bart Van Assche
2014-10-02 16:55                               ` Jens Axboe
     [not found]                                 ` <542D8368.8080604-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>
2014-10-03 13:01                                   ` Bart Van Assche
2014-10-03 14:24                                     ` Jens Axboe
     [not found]                               ` <542D8143.3050305-HInyCGIudOg@public.gmane.org>
2014-10-02 17:30                                 ` Christoph Hellwig
2014-10-06 11:16                                   ` Bart Van Assche
     [not found]                                     ` <54327A21.6070202-HInyCGIudOg@public.gmane.org>
2014-10-10 20:16                                       ` Roland Dreier
2014-09-23 16:32     ` Sagi Grimberg
     [not found]       ` <5421A093.1070203-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2014-09-23 19:02         ` Bart Van Assche
2014-09-24 12:22           ` Sagi Grimberg
2014-09-24 13:13             ` Bart Van Assche
     [not found]               ` <5422C395.7090902-HInyCGIudOg@public.gmane.org>
2014-09-24 13:38                 ` Sagi Grimberg
     [not found]                   ` <5422C970.4050306-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2014-09-24 13:43                     ` Sagi Grimberg
2014-10-07 12:51         ` Bart Van Assche
     [not found]           ` <5433E1B5.1030103-HInyCGIudOg@public.gmane.org>
2014-10-13  8:17             ` Sagi Grimberg
     [not found]               ` <543B8AB0.1090704-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2014-10-13  8:52                 ` Bart Van Assche
2014-10-01 16:14   ` [PATCH RFC] scsi_tcq.h: Add support for multiple hardware queues Bart Van Assche
2014-09-19 12:59 ` [PATCH 6/8] IB/srp: Avoid that I/O hangs due to a cable pull during LUN scanning Bart Van Assche
2014-09-19 12:59 ` [PATCH 7/8] IB/srp: Separate target and channel variables Bart Van Assche
2014-09-19 18:47   ` Sagi Grimberg
     [not found]   ` <541C28C8.7000007-HInyCGIudOg@public.gmane.org>
2014-09-23 16:07     ` Sagi Grimberg
2014-09-23 20:00       ` Bart Van Assche
2014-09-19 18:31 ` [PATCH RFC 0/8] IB/srp: Add multichannel support Jens Axboe
2014-09-22 14:37 ` Christoph Hellwig
     [not found]   ` <20140922143731.GA15377-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2014-09-22 16:25     ` Bart Van Assche
2014-09-22 16:31       ` Jens Axboe
2014-09-22 16:39         ` 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=542C31C4.1020702@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=Elliott@hp.com \
    --cc=bvanassche@acm.org \
    --cc=hch@infradead.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=ming.lei@canonical.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 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.