From: Jens Axboe <axboe@kernel.dk>
To: Ming Lei <ming.lei@redhat.com>, Christoph Hellwig <hch@infradead.org>
Cc: linux-block@vger.kernel.org, Omar Sandoval <osandov@fb.com>,
Jozef Mikovic <jmikovic@redhat.com>
Subject: Re: [PATCH 0/4] blk-mq-sched: allow to use hw tag for sched
Date: Wed, 26 Apr 2017 11:15:42 -0700 [thread overview]
Message-ID: <38bc590d-8ab4-5c88-d7e7-10cd2ec7d900@kernel.dk> (raw)
In-Reply-To: <20170426104842.GB28062@ming.t460p>
On 04/26/2017 03:48 AM, Ming Lei wrote:
> Hi Christoph,
>
> On Thu, Apr 20, 2017 at 04:30:42PM +0800, Ming Lei wrote:
>> Hi Christoph,
>>
>> On Wed, Apr 19, 2017 at 09:54:08PM -0700, Christoph Hellwig wrote:
>>> On Thu, Apr 20, 2017 at 09:03:47AM +0800, Ming Lei wrote:
>>>> If we don't need to reserve tag for internal command, I am happy
>>>> to fix it in the interim. However, the mtip32xx driver has to
>>>> ask blk-mq to reserve the tag zero for internal command. Then
>>>> if we can't allow the driver to use that reserved tag, it looks
>>>> quite awkward, doesn't it?
>>>
>>> It doesn't. Just offset the hardware tags by 1 from the blk-mq tags.
>>>
>>> But I'm pretty sure the hardware wouldn't require a specific tag
>>> for the internal ops.
>>
>> From mtip32xx code, the tag 0 is used to send internal command only, and
>> not used for submitting normal request.
>>
>> From code of mtip_issue_non_ncq_command() and mtip_issue_ncq_command(),
>> even same hardware address is writen to when issuing non-ncq and ncq
>> commands. So I think the internal ops and normal requests share one same
>> tag space on mtip32xx.
>>
>> Could you explain it a bit why you think the hw doesn't need the tag
>> for internal ops in this case?
>
> Gentle ping...
>
> Looks there are some choices for this issue:
>
> 1) if internal ops uses independent tag space
> - we need to clean up the mtip32xx driver
>
> 2) if internal ops shares tag space with normal request
> - export blk_mq_get_driver_tag() for mtip32xx
>
> or
>
> - use private way to send internal ops, and the drawback
> is that we still need to reserve tag and the reserved tag
> can't be used at all.
>
> From mtip32xx source code, I can see both share same tag space.
> When I try to search hw manual via google, not succeed yet.
>
> Christoph, could you share us your findings about if internal ops
> uses independent tag space or not?
Why aren't we just bypassing for RESERVED? If someone is asking
for an reserved tag, ensure that we use the right tag pool (sched
vs normal) and sub pool (reserved vs normal). Then insert just
bypasses the scheduler, like it already does if we have a driver
tag assigned already.
I've got a few of these cards, but traveling. I'll wire up something
and test it end this week.
--
Jens Axboe
next prev parent reply other threads:[~2017-04-26 18:15 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-15 12:38 [PATCH 0/4] blk-mq-sched: allow to use hw tag for sched Ming Lei
2017-04-15 12:38 ` [PATCH 1/4] block: respect BLK_MQ_F_NO_SCHED Ming Lei
2017-04-15 12:38 ` [PATCH 2/4] mtip32xx: pass BLK_MQ_F_NO_SCHED Ming Lei
2017-04-15 12:38 ` [PATCH 3/4] blk-mq: introduce BLK_MQ_F_SCHED_USE_HW_TAG Ming Lei
2017-04-15 12:38 ` [PATCH 4/4] mtip32xx: use BLK_MQ_F_USE_SCHED_TAG Ming Lei
2017-04-16 16:03 ` [PATCH 0/4] blk-mq-sched: allow to use hw tag for sched Ming Lei
2017-04-17 17:30 ` Omar Sandoval
2017-04-19 1:10 ` Ming Lei
2017-04-19 20:17 ` Jens Axboe
2017-04-20 0:44 ` Ming Lei
2017-04-20 0:55 ` Jens Axboe
2017-04-20 1:03 ` Ming Lei
2017-04-20 4:54 ` Christoph Hellwig
2017-04-20 8:30 ` Ming Lei
2017-04-26 10:48 ` Ming Lei
2017-04-26 18:15 ` Jens Axboe [this message]
2017-04-26 18:22 ` Jens Axboe
2017-04-27 3:14 ` Ming Lei
2017-04-27 13:49 ` Jens Axboe
2017-04-27 15:20 ` Christoph Hellwig
2017-04-27 15:46 ` Jens Axboe
2017-04-27 21:40 ` Jens Axboe
2017-04-27 6:32 ` Christoph Hellwig
2017-04-20 16:10 ` Jens Axboe
2017-04-21 10:54 ` Christoph Hellwig
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=38bc590d-8ab4-5c88-d7e7-10cd2ec7d900@kernel.dk \
--to=axboe@kernel.dk \
--cc=hch@infradead.org \
--cc=jmikovic@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=osandov@fb.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.