linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yufen Yu <yuyufen@huawei.com>
To: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Cc: <john.garry@huawei.com>, Ming Lei <ming.lei@redhat.com>,
	"axboe@kernel.dk" <axboe@kernel.dk>, <hare@suse.de>,
	Bart Van Assche <bvanassche@acm.org>
Subject: [Question] abort shared tags for SCSI drivers
Date: Thu, 16 Jan 2020 12:06:02 +0800	[thread overview]
Message-ID: <bd959b9f-78dd-e0e7-0421-8d7e3cd2f41b@huawei.com> (raw)

Hi, all

Shared tags is introduced to maintains a notion of fairness between
active users. This may be good for nvme with multiple namespace to
avoid starving some users. Right?

However, I don't understand why we introduce the shared tag for SCSI.
IMO, there are two concerns for scsi shared tag:

1) For now, 'shost->can_queue' is used as queue depth in block layer.
And all target drivers share tags on one host. Then, the max tags for
each target can get:

	depth = max((bt->sb.depth + users - 1) / users, 4U);

But, each target driver may have their own capacity of tags and queue depth.
Does shared tag limit target device bandwidth?

2) When add new target or remove device, it may need to freeze other device
to update hctx->flags of BLK_MQ_F_TAG_SHARED. That may hurt performance.

Recently we discuss abort hostwide shared tags for SCSI[0] and sharing tags
across hardware queues[1]. These discussion are abort shared tag. But, I
confuse whether shared tag across hardware queues can solve my concerns as mentioned.

I have not deeply understand for SCSI and please correct me if I got wrong.

[0] https://www.spinics.net/lists/linux-scsi/msg136131.html
[1] https://www.spinics.net/lists/linux-block/msg47504.html

Thanks,
Yufen

             reply	other threads:[~2020-01-16  4:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16  4:06 Yufen Yu [this message]
2020-01-16  9:03 ` [Question] abort shared tags for SCSI drivers Ming Lei
2020-01-16 12:17   ` [Question] about " John Garry
2020-01-16 15:17   ` [Question] abort " James Bottomley
2020-01-17  7:19   ` [Question] about " Yufen Yu
2020-01-17 10:16     ` Ming Lei
2020-01-19 13:57       ` Yufen Yu

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=bd959b9f-78dd-e0e7-0421-8d7e3cd2f41b@huawei.com \
    --to=yuyufen@huawei.com \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=hare@suse.de \
    --cc=john.garry@huawei.com \
    --cc=linux-block@vger.kernel.org \
    --cc=ming.lei@redhat.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;
as well as URLs for NNTP newsgroup(s).