Re: FC_PORTSPEED semantics confusion and zfcp regression

[Steffen Maier <maier@linux.vnet.ibm.com>]

Hi Neerav,

thanks very much for your quick reply!

On 08/09/2012 09:29 PM, Parikh, Neerav wrote:
>> -----Original Message-----
>> From: linux-scsi-owner@vger.kernel.org [mailto:linux-scsi-
>> owner@vger.kernel.org] On Behalf Of Steffen Maier
>> Sent: Thursday, August 09, 2012 9:15 AM

>> Lately, commit
>> a9277e7783651d4e0a849f7988340b1c1cf748a4
>> "[SCSI] scsi_transport_fc: Getting FC Port Speed in sync with FC-GS"
>> reverted this.
>> (See also http://marc.info/?l=linux-scsi&m=132892310322550&w=2.)

> One thing that I seem to miss is the RPSC ELS have some different definitions
> for speed as compared to the FC_PORTSPEED before this commit as well. Does the
> zfcp HBA FW do some internal conversion resulting into speed values that
> were in sync with the prior FC_PORTSPEED values?

Assuming you refer to the reversed bit order, then this is handled by 
the HBA and therefore matches the prior FC_PORTSPEED values.

kernel before a9277e7                FC-GS RPSC ELS Sec.6.2.3.3.8+9
                                      Bit  Description
------------------------------------|------------------------------
#define FC_PORTSPEED_UNKNOWN      0  -
#define FC_PORTSPEED_1GBIT        1  15    1 Gb/s capable
#define FC_PORTSPEED_2GBIT        2  14    2 Gb/s capable
#define FC_PORTSPEED_4GBIT        4  13    4 Gb/s capable
#define FC_PORTSPEED_10GBIT       8  12   10 Gb/s capable
#define FC_PORTSPEED_8GBIT     0x10  11    8 Gb/s capable
#define FC_PORTSPEED_16GBIT    0x20  10   16 Gb/s capable
                                       9   20 Gb/s capable
                                       8   32 Gb/s capable
                                       7   40 Gb/s capable
                                      6-2  Reserved
                                       1   Unknown
#define FC_PORTSPEED_NOT_NEGOTIATED
                           (1 << 15)   0   Speed not established

>> I don't mind converting zfcp to an explicit finite bit
>> conversion based on individually defined constants, esp. since all
>> other
>> FC LLDDs (qla2xxx, bfa, lpfc, ibmvscsi, fnic, mptfc) seem to do so
>> already. The only slight drawback I can see is that the code needs to
>> be touched for new HBA generations supporting new port speeds.

I think, I'm going to bring zfcp in line with the other LLDs and do an 
explicit conversion for the following reasons:
Independence of any current kernel port speed semantics.
I have to do service for enterprise distros anyway (even if you revert 
your commit upstream) since some seem to have to picked up a9277e7 already.

>> 3) Should we have port speed defines for both RPSC ELS (in
>> include/fc/fc_els.h?) and FDMI port attributes (in
>> include/scsi/scsi_transport_fc.h? unless the bit semantic change gets
>> reverted)?
>>
>> This way I could reuse the former to convert to the latter within zfcp
>> and other users can reuse it with regard to RPSC ELS. I would send a
>> patch if we agree on this.

I guess, there is no other user currently so I might just code it inside 
zfcp without definitions in fc_els.h unless someone wants me to.

> Also, regardless of the approach you decide on wouldn't zfcp need to make
> sure the speed values reported by HBA FW is in sync with the in kernel
> values?

Not necessarily, because we don't synchronize the bit semantics between 
HBA and kernel, but between HBA and FC-GS RPSC ELS in reversed bit 
order. If the kernel would also remain using the semantics of FC-GS RPSC 
ELS in reversed bit order, then the HBA values would automatically match 
the kernel definitions.
However, that's no longer relevant with an explicit conversion in zfcp.

Regards,
Steffen

Linux on System z Development

IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

--
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