From: Bart Van Assche <Bart.VanAssche-Sjgp3cTcYWE@public.gmane.org>
To: "jgg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org"
<jgg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>,
"dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org"
<dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: "linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"loberman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org"
<loberman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH v5 0/3] IB/srp patches for kernel v4.16
Date: Tue, 23 Jan 2018 21:35:05 +0000 [thread overview]
Message-ID: <1516743303.3339.36.camel@wdc.com> (raw)
In-Reply-To: <1516727351.27592.46.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Tue, 2018-01-23 at 12:09 -0500, Doug Ledford wrote:
> I took the series as is. But, I don't know the target core well enough
> to know what the third patch actually does (that doesn't impact my
> decision to take it, it's a knob into the target core to allow you to
> tweak things, that's obvious enough and since you find it useful, I have
> no problem with it). I know the cmd_per_lun setting sets the queue
> depth of the scsi device on the initiator side, I would have assumed
> that normally mirrors the advertised ability of the target, but this
> patch now makes me think otherwise. So what does this third patch
> actually do to the target code?
Hello Doug,
Thanks! Regarding the third patch: the word "target" in the "target_can_queue"
member refers to a parameter at the SCSI initiator side. The object hierarchy
in the Linux SCSI initiator stack is as follows:
* The top level objects are called SCSI hosts (struct Scsi_Host). These objects
have a representation in sysfs under /sys/class/scsi_host/ and also under
/sys/class/scsi_host.
* The next level objects are called SCSI targets (struct scsi_target). There is
one directory per SCSI target in sysfs, e.g. /sys/bus/scsi/devices/target1:0:0.
* The lowest level objects are called SCSI devices (struct scsi_device). There
is one directory per SCSI device instance in /sys/class/scsi_device/ and also
in /sys/bus/scsi/devices/.
Each SCSI device is identified by four numbers, called the host, channel, ID
and LUN indexes. Usually these four numbers are mentioned in the order H:C:I:L.
The host part (H) identifies the SCSI host. The H:C:I part identifies the SCSI
target. From drivers/scsi/scsi_scan.c:
dev_set_name(dev, "target%d:%d:%d", shost->host_no, channel, id);
And from drivers/scsi/scsi_sysfs.c:
dev_set_name(&sdev->sdev_gendev, "%d:%d:%d:%llu",
sdev->host->host_no, sdev->channel, sdev->id, sdev->lun);
Unlike other block drivers, the SCSI core imposes more restrictions on the
number of commands that can be queued than just the queue depth of the block
layer device. The maximum number of commands that the block layer is allowed to
queue per SCSI host is Scsi_Host.can_queue. The maximum number of commands
that can be queued per SCSI target is scsi_target.can_queue. And the limit for
a single SCSI device is Scsi_Host.cmd_per_lun. See also scsi_host_is_busy(),
scsi_target_is_busy() and scsi_device_is_busy() in the SCSI core.
Bart.
next prev parent reply other threads:[~2018-01-23 21:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-22 22:27 [PATCH v5 0/3] IB/srp patches for kernel v4.16 Bart Van Assche
[not found] ` <20180122222713.13197-1-bart.vanassche-Sjgp3cTcYWE@public.gmane.org>
2018-01-22 22:27 ` [PATCH v5 1/3] kobject: Export kobj_ns_grab_current() and kobj_ns_drop() Bart Van Assche
2018-01-22 22:27 ` [PATCH v5 2/3] IB/srp: Add RDMA/CM support Bart Van Assche
2018-01-22 22:27 ` [PATCH v5 3/3] IB/srp: Add target_can_queue login parameter Bart Van Assche
2018-01-23 17:09 ` [PATCH v5 0/3] IB/srp patches for kernel v4.16 Doug Ledford
[not found] ` <1516727351.27592.46.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-01-23 21:35 ` Bart Van Assche [this message]
[not found] ` <1516743303.3339.36.camel-Sjgp3cTcYWE@public.gmane.org>
2018-01-25 15:47 ` Doug Ledford
[not found] ` <1516895274.27592.125.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-01-25 19:06 ` Bart Van Assche
[not found] ` <a136f97d-cc29-3fb1-6692-770eb11eba13-Sjgp3cTcYWE@public.gmane.org>
2018-01-25 20:00 ` Doug Ledford
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=1516743303.3339.36.camel@wdc.com \
--to=bart.vanassche-sjgp3ctcywe@public.gmane.org \
--cc=dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=jgg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=loberman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox