On Fri, May 21, 2010 at 11:25 AM, Smith, Stan <[email protected]> wrote: > Hal Rosenstock wrote: >> On Thu, May 20, 2010 at 3:43 PM, Smith, Stan <[email protected]> >> wrote: >>> >>> Skip the destination lid byte-order swap as it's already in the >>> correct order for vendor IBAL. >>> >>> Permits 'osmtest -f f -s4' test to correctly complete. >>> >>> signed-off-by: stan smith <[email protected]> >>> >>> --- a/ulp/opensm/user/osmtest/osmtest.c Thu May 20 12:34:59 2010 >>> +++ b/ulp/opensm/user/osmtest/osmtest.c Thu May 20 12:36:33 2010 @@ >>> -2885,7 +2885,11 @@ >>> memset(&context, 0, sizeof(context)); >>> >>> slid = cl_ntoh16(p_osmt->local_port.lid); >>> +#ifdef OSM_VENDOR_INTF_AL >>> + dlid = p_osmt->local_port.sm_lid; // already in correct >>> byte-order +#else >>> dlid = cl_ntoh16(p_osmt->local_port.sm_lid); >>> +#endif >> >> Seems weird to me that port LID would be in network order but SM LID >> is not (for OSM_VENDOR_INTF_AL). >> >> -- Hal > > IBAL provides numerous items in ready to send network byte order. > I believe the !OSM_VENDOR+INTF_AL clause should actually be hton16.
It looks to me like the LIDs in p_osmt->local_port should be in network order so I would think the operation is either ntoh16 or nothing at all rather than hton16. My point was that the LID and SMLID in p_osmt->local_port should be consistent in terms of their byte ordering. Why is that for IBAL ? A larger issue is that there appears to be byte order confusion as both slid/dlid are also defined as ib_net16_t (and also in many routines in osmtest) but are really in host order. -- Hal > >> >>> >>> /* >>> * Do a blocking query for the PathRecord. >>> _______________________________________________ >>> ofw mailing list >>> [email protected] >>> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw > > _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
