From: m@bjorling.me (Matias Bjorling)
Subject: [PATCH 3/3] NVMe: Convert to blk-mq
Date: Tue, 22 Oct 2013 20:55:37 +0200 [thread overview]
Message-ID: <5266CA29.2020308@bjorling.me> (raw)
In-Reply-To: <alpine.LRH.2.03.1310221011570.4763@AMR>
Den 22-10-2013 18:55, Keith Busch skrev:
> On Fri, 18 Oct 2013, Matias Bj?rling wrote:
>> On 10/18/2013 05:13 PM, Keith Busch wrote:
>>> On Fri, 18 Oct 2013, Matias Bjorling wrote:
>>>> The nvme driver implements itself as a bio-based driver. This
>>>> primarily
>>>> because of high lock congestion for high-performance nvm devices. To
>>>> remove the congestion within the traditional block layer, a
>>>> multi-queue
>>>> block layer is being implemented.
>
>>>> - result = nvme_map_bio(nvmeq, iod, bio, dma_dir, psegs);
>>>> - if (result <= 0)
>>>> + if (nvme_map_rq(nvmeq, iod, rq, dma_dir))
>>>> goto free_cmdid;
>>>> - length = result;
>>>>
>>>> - cmnd->rw.command_id = cmdid;
>>>> + length = blk_rq_bytes(rq);
>>>> +
>>>> + cmnd->rw.command_id = rq->tag;
>>>
>>> The command ids have to be unique on a submission queue. Since each
>>> namespace's blk-mq has its own 'tags' used as command ids here but
>>> share
>>> submission queues, what's stopping the tags for commands sent to
>>> namespace
>>> 1 from clashing with tags for namespace 2?
>>>
>>> I think this would work better if one blk-mq was created per device
>>> rather than namespace. It would fix the tag problem above and save a
>>> lot of memory potentially wasted on millions of requests allocated that
>>> can't be used.
>>
>> You're right. I didn't see the connection. In v3 I'll push struct
>> request_queue to nvme_dev and map the queues appropriately. It will
>> also fix the command id issues.
>
> Just anticipating a possible issue with the suggestion. Will this
> separate
> the logical block size from the request_queue? Each namespace can have
> a different format, so the block size and request_queue can't be tied
> together like it currently is for this to work.
If only a couple of different logical sizes are to be expected (1-4), we
can keep a list of already initialized request queues, and use the one
that match an already initialized?
Axboe, do you know of a better solution?
WARNING: multiple messages have this Message-ID (diff)
From: Matias Bjorling <m@bjorling.me>
To: Keith Busch <keith.busch@intel.com>, axboe@kernel.dk
Cc: willy@linux.intel.com, linux-kernel@vger.kernel.org,
linux-nvme@lists.infradead.org
Subject: Re: [PATCH 3/3] NVMe: Convert to blk-mq
Date: Tue, 22 Oct 2013 20:55:37 +0200 [thread overview]
Message-ID: <5266CA29.2020308@bjorling.me> (raw)
In-Reply-To: <alpine.LRH.2.03.1310221011570.4763@AMR>
Den 22-10-2013 18:55, Keith Busch skrev:
> On Fri, 18 Oct 2013, Matias Bjørling wrote:
>> On 10/18/2013 05:13 PM, Keith Busch wrote:
>>> On Fri, 18 Oct 2013, Matias Bjorling wrote:
>>>> The nvme driver implements itself as a bio-based driver. This
>>>> primarily
>>>> because of high lock congestion for high-performance nvm devices. To
>>>> remove the congestion within the traditional block layer, a
>>>> multi-queue
>>>> block layer is being implemented.
>
>>>> - result = nvme_map_bio(nvmeq, iod, bio, dma_dir, psegs);
>>>> - if (result <= 0)
>>>> + if (nvme_map_rq(nvmeq, iod, rq, dma_dir))
>>>> goto free_cmdid;
>>>> - length = result;
>>>>
>>>> - cmnd->rw.command_id = cmdid;
>>>> + length = blk_rq_bytes(rq);
>>>> +
>>>> + cmnd->rw.command_id = rq->tag;
>>>
>>> The command ids have to be unique on a submission queue. Since each
>>> namespace's blk-mq has its own 'tags' used as command ids here but
>>> share
>>> submission queues, what's stopping the tags for commands sent to
>>> namespace
>>> 1 from clashing with tags for namespace 2?
>>>
>>> I think this would work better if one blk-mq was created per device
>>> rather than namespace. It would fix the tag problem above and save a
>>> lot of memory potentially wasted on millions of requests allocated that
>>> can't be used.
>>
>> You're right. I didn't see the connection. In v3 I'll push struct
>> request_queue to nvme_dev and map the queues appropriately. It will
>> also fix the command id issues.
>
> Just anticipating a possible issue with the suggestion. Will this
> separate
> the logical block size from the request_queue? Each namespace can have
> a different format, so the block size and request_queue can't be tied
> together like it currently is for this to work.
If only a couple of different logical sizes are to be expected (1-4), we
can keep a list of already initialized request queues, and use the one
that match an already initialized?
Axboe, do you know of a better solution?
next prev parent reply other threads:[~2013-10-22 18:55 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-18 13:14 [PATCH 0/3] Convert from bio-based to blk-mq v2 Matias Bjorling
2013-10-18 13:14 ` Matias Bjorling
2013-10-18 13:14 ` [PATCH 1/3] blk-mq: call exit_hctx on hw queue teardown Matias Bjorling
2013-10-18 13:14 ` Matias Bjorling
2013-10-18 13:14 ` [PATCH 2/3] NVMe: Extract admin queue size Matias Bjorling
2013-10-18 13:14 ` Matias Bjorling
2013-10-18 13:14 ` [PATCH 3/3] NVMe: Convert to blk-mq Matias Bjorling
2013-10-18 13:14 ` Matias Bjorling
2013-10-18 15:13 ` Keith Busch
2013-10-18 15:13 ` Keith Busch
2013-10-18 19:06 ` Matias Bjørling
2013-10-18 19:06 ` Matias Bjørling
2013-10-22 16:55 ` Keith Busch
2013-10-22 16:55 ` Keith Busch
2013-10-22 18:55 ` Matias Bjorling [this message]
2013-10-22 18:55 ` Matias Bjorling
2013-10-22 19:52 ` Keith Busch
2013-10-22 19:52 ` Keith Busch
2013-10-18 15:48 ` [PATCH 0/3] Convert from bio-based to blk-mq v2 Matthew Wilcox
2013-10-18 15:48 ` Matthew Wilcox
2013-10-18 19:10 ` Matias Bjørling
2013-10-18 19:10 ` Matias Bjørling
2013-10-18 19:21 ` Matias Bjorling
2013-10-18 19:21 ` Matias Bjorling
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=5266CA29.2020308@bjorling.me \
--to=m@bjorling.me \
/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.