[ofw] [PATCH] osmtest - bye order already set for vendor IBAL.

[Hal Rosenstock]

On Fri, May 21, 2010 at 11:25 AM, Smith, Stan <stan.smith at intel.com> wrote:
> Hal Rosenstock wrote:
>> On Thu, May 20, 2010 at 3:43 PM, Smith, Stan <stan.smith at intel.com>
>> 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 <stan.smith at intel.com>
>>>
>>> --- 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
>>> ofw at lists.openfabrics.org
>>> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
>
>