On Thu, 2014-01-16 at 20:54 +0000, Quinn Tran wrote:
> 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.
>
Fair enough. I'm currently planning for targetcli to (by default)
generate $NPIV_WWPN + $NPIV_WWNN values for end users in NAA2 format.
Optionally, advanced versions will be able to provide their own
$NPIV_WWPN + $NPIV_WWNN values at port creation time if necessary.
> 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.
>
Note that rtslib/targetcli can always use 'free form' names, for which
user can pass any value into /sys/kernel/config/target/$FABRIC/$WWPN.
>
> 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)
>
Ok, so we've been using NAA2 formatting for all FC/FCoE ports
represented in configfs thus far.
>
> ----
> <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"
>
Mmmm, so target core is exposing the SCSI name string prefix matching
what's in /sys/kernel/config/target/$FABRIC/WWPN.
For non NPIV qla2xxx + tcm_fc(FCoE), this ends up being:
21:00:XX:XX:XX:XX:XX:XX,t,0x0001
So this will need to be changed for the FC/FCoE cases to follow the
'naa.' prefixed format mentioned above. AFAIK this is only used for
information purposes, so it's fairly low priority atm.
--nab
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
