Re: [PATCH 6/8] target_core_spc: Include target device descriptor in VPD page 83

[Hannes Reinecke <hare@suse.de>]

On 12/17/2013 09:01 PM, Nicholas A. Bellinger wrote:
> On Tue, 2013-12-17 at 11:50 -0800, Nicholas A. Bellinger wrote:
>> On Tue, 2013-12-17 at 09:18 +0100, Hannes Reinecke wrote:
>>> We should be including a descriptor referring to the target device
>>> to allow identification of different TCM instances.
>>>
>>> Signed-off-by: Hannes Reinecke <hare@suse.de>
>>> ---
>>>  drivers/target/target_core_spc.c | 43 +++++++++++++++++++++++++++++++++++++++-
>>>  1 file changed, 42 insertions(+), 1 deletion(-)
>>>
>>
>> One issue with this patch.  The local buffer in spc_emulate_inquiry is
>> currently hardcoded to SE_INQUIRY_BUF=512, so two large scsi name
>> designators could overflow here..
>>
>> So for the largest case with EVPD=0x83, this would be:
>>
>> 4 bytes for header +
>> 20 bytes for NAA IEEE Registered Extended Assigned designator +
>> 56 bytes for T10 Vendor Identifier +
>> 8 bytes for Relative target port +
>> 8 bytes for Target port group +
>> 8 bytes for Logical unit group +
>> 256 bytes for SCSI name (target port) +
>> 256 bytes for SCSI name (target device) == 616 bytes.
>>
>> So for good measure, bumping up SE_INQUIRY_BUF to 1024.
>>
> 
> Mmmm, looking at this again, is reporting back two SCSI names in
> EVPD=0x83 with different associations (one for target port, and one for
> target device) really necessary..?
> 
> Doesn't the existing target port association report back the same
> information..?
> 
No.
'Target port' is the identification for the port handling the
request, which is contained within a target device.

The reason why we need this is that we want to identify the scope of
the Target port group number.

Target port group numbers are relative to the encompassing target
device, so when we're having _several_ target devices they might
well provide us with identical target port group numbers.

For explicit ALUA each target port group within a target device can
be thought of a 'scheduling domain', ie if I sent STPG to one of the
devices in that domain there is a _high_ likelihood that _every_
device within that scheduling domain will be affected.
So I can be slightly smarter here and just send one STPG and then
wait for the resulting states on all affected devices.

If I don't have this information I am required to send STPG to each
and every device, thereby flooding the target controller with STPGs
for the same target port group.

So yes, we should be furnishing both.
In addition it's the only sane way of identifying the array :-)

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html