Are the PathRecord reserved components really reserved?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

I am looking into the OFED code for the component mask bits of the
PathRecord requests and I need some further explanation.

The IB specification in section "15.2.5.16 PathRecord, table 207
PathRecord" defines the first two components as "Reserved". Each one of
them is 32 bits long and the description of the first one is "Reserved"
while the description of the second reserved component is "Offset for
alignment".

However, in the file "include/rdma/ib_sa.h" where the component mask
bits for the Path Records are defined, the 1st and 2nd component are
combined together under the name IB_SA_PATH_REC_SERVICE_ID.


#define IB_SA_PATH_REC_SERVICE_ID   (IB_SA_COMP_MASK( 0) |\
                                     IB_SA_COMP_MASK( 1))


The same definition exists in the OpenSM code in file
"include/iba/ib_types.h"


/* Path Record Component Masks */
#define  IB_PR_COMPMASK_SERVICEID_MSB     (CL_HTON64(((uint64_t)1)<<0))
#define  IB_PR_COMPMASK_SERVICEID_LSB     (CL_HTON64(((uint64_t)1)<<1))
.....
.....
#define  IB_PR_COMPMASK_SERVICEID (IB_PR_COMPMASK_SERVICEID_MSB | \
                                   IB_PR_COMPMASK_SERVICEID_LSB)


Why are these fields named as "SERVICE_ID"? I would expect something
like IB_SA_PATH_REC_RESERVED_1 and IB_SA_PATH_REC_RESERVED_2 according
to the specs. Are they really reserved or used, and if they are used,
when does this happen?

Vangelis

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux