[ofw] ib_portinfo_record_t padding history?

[Fab Tillier]

Smith, Stan wrote on Tue, 18 May 2010 at 16:40:30

> Fab Tillier wrote:
>> Smith, Stan wrote on Tue, 18 May 2010 at 14:18:09
>> 
>>> Indeed a problem arises in osmtest when building a fabric inventory
>>> file 'osmtest.dat' via 'osmtest -f c'.
>>> The problem is exactly that of an SA response containing an array of
>>> ib_portinfo_records. With the padding the 2nd ib_portinfo_record[1]
>>> index computation is incorrectly offset by 2 bytes.
>> 
>> Is the array being addressed as an array, or each entry being
>> accessed using ib_get_query_result (or ib_get_query_portinfo_rec?)
> 
> From ulp\opensm\user\include\osm_vendor_sa_api.h
> 
> (ib_portinfo_record_t *) osmv_get_query_result(p_result_madw,
> result_index);
> 
>> Which direction are you off by 2?  Is the next entry 2 bytes too
>> soon, or two bytes too late?
> 
> Actual data in the result_madw is correct;

Just to be sure, you mean that the following code won't trip the following asserts:

CL_ASSERT( osmv_get_query_results( result_madw, 0 ) == (void*)((ib_sa_mad_t*)result_madw)->data) );
CL_ASSERT( osmv_get_query_results( result_madw, 1 ) == (void*)((ib_sa_mad_t*)result_madw)->data + 64) );

> calculation of result_index
> 'osmv_get_query_result()'is off by +2. I did not verify the 3rd
> portinfo_record start. Once I removed the ib_portinfo_record_t padding
> the problem was resolved. The gold standard inventory file was created
> using a Linux osmtest & Linux opensm. Sans the differences in where
> openSM is running, inventory files should be very similar.

Ok, this makes no sense.  You're accessing the entries using osmv_get_query_result, but not getting the right attributes?  Is ib_get_attr_size not returning 64 for an input attr_offset of 8?

The padding doesn't come into play here, as you're casting to ib_portinfo_record_t after all the pointer arithmetic is done - everything is based on ib_get_attr_size, and attr_offset.

Now, you *should* have a pad of 6 bytes in the MAD response, that is, each portinfo_record should be 64 bytes apart.  If they are not 64 bytes apart, the sender is broken.  If they are 64 bytes apart, some of the logic in osmv_get_query_result is broken.

>> You're running osmtest on Windows against OpenSM on Linux?  Or both
>> on Windows?  Both on Linux?
> 
> gold std osmtest.dat (inventory file) was generated completely on Linux.
> Windows osmtest using a Linux openSM with Linux generated inventory file
> works correctly 'osmtest -f v'; the goal.
> 
> Switch to a windows generated inventory file and same osmtest fails.
> Further examination of the windows inventory file showed the off-by-2
> problem as the DEFINE_PORT entries were bad.

How do you generate the inventory file on Windows?  Is that what you're debugging now?

>> Can you check that offset is 8, not 7, in the RMPP response to the
>> query?
> 
> offset == 8.

Ok, so are the portinfo_records 64-byte apart in the response MAD?

-Fab