On Tue, 2018-01-23 at 21:35 +0000, Bart Van Assche wrote:
> 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.
Sure, I know most of the stuff above, as I used to maintain the aic7xxx
driver back when SCSI was actually popular. But the target layer in the
scsi core didn't exist back in the day. Our structure was block layer-
>scsi disk/scsi cd-rom drivers->scsi core->scsi low level driver. The
setup back then was that block layer had its own request queue depth,
then it would pass block layer requests to the scsi disk driver that
turned them into scsi command blocks and would issue up to host-
>cmd_per_lun scbs at a time (assuming the device allowed tagged
commands, without that you only got one at a time). Being out of the
loop, but knowing how things used to work, I figured the SRP driver
already controlled how many commands would be presented to the target at
the other side by hooking into the scsi core as a low level device
driver and setting cmd_per_lun. I think what's happened in the
intervening years is that they seem to have taken the scsi disk driver
and scsi cd-rom drivers and replaced them with a generic target driver
that handles all block targets and then uses the old scsi disk and scsi
cd-rom drivers as personalities for the given target, yes? And they now
allow per-target command depth setting where as in the old days the
queue depth for all tagged allowed targets was the device driver's
cmd_per_lun, yes? (Back when I worked on this, multi-lun devices were
not well supported, and cmd_per_lun, which should have really been
cmd_per_device, was truly applied per lun and could easily cause a
tagged device to have many more outstanding commands than intended if it
was a multi-lun tagged capable device, at least on the old aic7xxx
driver it could) So that the queue depth on devices now a days is
essentially min(target->can_queue, shost->cmd_per_lun), yes?
> 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.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDDAttachment:
signature.asc
Description: This is a digitally signed message part
