Nicholas,
Comments inline. Thanks.
<SNIP>
>Bullet 3) Generating NPIV WWPN id: Qlogic overall strategy for this
>question is: Qla2xxx driver is a common driver being used by various
>hardware vendors(HP, IBM, Dell, etc..). Each vendors have a different
>scheme on how to generate the WWPN value. QLogic's design decision is to
>push that up to the user app to generate these values rather having
>QLA2xxx generating it dynamically.
So question here was not contents of the NPIV WWPN value, but rather if
the NPIV WWPN and NPIV WWNN are always expected to have the same suffix.
Eg, is it safe to assume that the '21' and '20' prefixes for NPIV WWPN +
NPIV WWNN are the only different part of the $NPIV_WWPN:$NPIV_WWNN tuple
passed into fc_vport_create()..?
If so, I'd like to remove $NPIV_WWNN from being passed into configfs,
and simply generate this value internally, eg:
/sys/kernel/config/target/qla2xxx_npiv/$PHYS_WWPN:$NPIV_WWPN
<SNIP>
QT> Mis-read this one.
It's not safe to assume "21" & "20" as the standardize prefixes and the
rest of the $WWPN/$WWNN will be the same. While it is common to see "21" &
"20" (i.e. Network Addr Authority/NAA 2 format) on a lot of adapters. The
common case that we see only cover 1 NAA format. I've seen the NAA5
format float around on different adapters.
I don't want to paint us in to a corner, that will require future code
change in this area. The user that generate the $NPIV_WWPN + $NPIV_WWNN
may decide to use another NAA format where it will not match this
implementation.
By collapsing the $NPIV_WWNN into the driver, its takes away the option
for an administrator of a large SAN to assign/identify storage chassis
using $WWNN. Even though it is clunky to carry around.
I prefer the format "$PHYS_WWPN@$NPIV_WWPN:$NPIV_WWNN" with the "@" key,
for the case where the user download an older version of RSTLIB that still
follow the older format/backward compatible. The '@' key inside the
driver provides the distinction of the new configfs format. No preference
on $PHYS_WWPN appear at the front or back.
Network address authority Format:
NAA1 =10-00-vv-vv-vv-ss-ss-ss
NAA2 =2x-xx-vv-vv-vv-ss-ss-ss
NAA5 =5v-vv-vv-vs-ss-ss-ss-ss
NAA6 =6?-Š (16 bytes/32 hex digits, not applicable for HW adapter)
x=vendor code (0-00=wwnn 1-00=wwpn)
v=vendor id
s=serial number (NAA5: user may decide to use WWPN=N & WWNN=N+1)
----
<SNIP>
>Bullet 4) VPD Page 83h, SCSI name string. If you implying to use the WWPN
>as part of the "SCSI name string", the answer is the same as previous
>bullet. In this case, the setup up script would have to extract the data
>from configfs in order to generate the "SCSI name string"
This question was geared toward how SCSI name should be represented in
INQUIRY EVPD=0x83 for NPIV ports.
For physical ports, this ends up being the 21:00:00:XX:XX:XX:XX:XX value
matching what is passed to configfs. For virtual ports the passed
$NPIV_WWPN part would be here in similar format, but the question was if
the port_id should also be appended here similar to existing 'lsscsi
--transport' output, eg:
root@devstack:~# lsscsi --transport
[0:0:0:0] disk ata: /dev/sda
[91:0:0:0] disk fc:0x21111111222222220x610101 /dev/sdb
<SNIP>
SPC4 rev 36n, section 7.8.6.11 >
The SCSI NAME STRING field starts with either:
...
b) the four UTF-8 characters 'naa.' concatenated with 16 or 32 hexadecimal
digits for an NAA identifier
(see 7.8.6.6). The first hexadecimal digit shall be the most significant
four bits of the first byte (i.e.,
most significant byte) of the NAA identifier; or
...
"If the ASSOCIATION field is set to 01b (i.e., target port), the SCSI NAME
STRING field ends with the five UTF-8
characters ',t,0x' concatenated with two or more hexadecimal digits as
defined in the applicable SCSI
transport protocol standard."
...
QT> If I read SPC4 correctly, the format is as follow (minor tweak). For
FC, there is only 1 format (i.e. Association field = 1). Correct the
format if you read it differently.
[91:0:0:0] disk fc:naa.2111111122222222,t,0x610101 /dev/sdb
Scsi name string = "naa.2111111122222222,t,0x610101"
---
Regards,
Quinn Tran
________________________________
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
<<attachment: winmail.dat>>
