[openib-general] RMPP Message Format Errors

[Hal Rosenstock]

On Thu, 2005-09-15 at 04:01, Eitan Zahavi wrote:
> Now lets go back to the test:
> 
> I use a machine connected through a single switch (IS3) to itself.
> 
> I use osmtest -f c to get Nodes,Ports and PathRecords from the SM.
> 
>  From OpenSM Log file I see:
> Sep 15 09:47:37 531029 [8003] -> osm_nr_rcv_process: Returning 3 records.
> Sep 15 09:47:37 538586 [C004] -> osm_pir_rcv_process: Returning 27 records.
> 
> So we can conclude the following RMPP transactions should be sent:
> 1. NodeRec:
>     attrOffset is 14 and each record size with padding is 112bytes.
>     The RMPP with 336byte data should require 2 segments = ceiling(336/200).
>     First segment paylen should be 336 + 2 * 20 = 376.
>     Last segment paylen should be  336 - 200 + 20 = 156.
> 
> 2. PortInfoRecords:
>     attrOffset is 8 and each record size with padding is 64bytes.
>     The RMPP with 1728 = 27 * 64byte data should require 9 segments = ceiling(1728/200).
>     First segment paylen should be 1728 + 9 * 20 = 1908.
>     Lat segment paylen should be  1728 - 8*200 + 20 = 148.
> 
> What we see in the attached analyzer capture:
> NodeInfoRec
> Attr          Expected Measured
> Num Segments	2	2
> First Paylen	376	376
> Last Paylen	156	156
> 
> PortInfoRec
> Attr          Expected Measured
> Num Segments	9	9
> First Paylen	1908	1908
> Last Paylen	148	148
> 
> So the response on the wire is 100% OK. Thanks Sean.
> 
> Now I go to the SA client section:
> 
>  From osmtest log I see:
> 
> NodeInfoRec:
> Aug 21 14:46:56 [4017F6C0] -> __osmv_send_sa_req: Waiting for async event.
> Aug 21 14:46:56 [40D87BB0] -> osm_mad_pool_get: [
> Aug 21 14:46:56 [40D87BB0] -> osm_vendor_get: [
> Aug 21 14:46:56 [40D87BB0] -> osm_vendor_get: Acquiring UMAD for p_madw = 0x807b8a4, size = 256.
> Aug 21 14:46:56 [40D87BB0] -> osm_vendor_get: Acquired UMAD 0x807c198, size = 256.
> Aug 21 14:46:56 [40D87BB0] -> osm_vendor_get: ]
> Aug 21 14:46:56 [40D87BB0] -> osm_mad_pool_get: Acquired p_madw = 0x807b898, p_mad = 0x807c1d0, size = 256.
> Aug 21 14:46:56 [40D87BB0] -> osm_mad_pool_get: ]
> Aug 21 14:46:56 [40D87BB0] -> __osmv_sa_mad_rcv_cb: [
> Aug 21 14:46:56 [40D87BB0] -> __osmv_sa_mad_rcv_cb: Count = 1 = 200 / 112 (88)
> Aug 21 14:46:56 [40D87BB0] -> osmtest_query_res_cb: [
> Aug 21 14:46:56 [40D87BB0] -> osmtest_query_res_cb: ]
> Aug 21 14:46:56 [40D87BB0] -> __osmv_sa_mad_rcv_cb: ]
> I wonder how come the received MAD is only of 256 bytes. I expected it to be of headers + data = 56 + 336 = 392byte.

Isn't the vendor_get above for the SA request being sent ? That's why
the buffer allocated here is 256 bytes.

The OpenIB umad_receiver is the only handling the RMPP receive. It
allocates the proper size buffer for this. It first tries with a 256
byte buffer and if a bigger one is needed, the first umad_recv fails
with the length of the buffer needed and then is reissued. 

The length that __osmv_sa_mad_rcv_cb is seeing is wrong. I'm not sure
why yet (I am looking into this) but the length will not be what you are
expecting due to the following:

Buffers supplied to and from RMPP are assembled and contain 1 SA
header's worth and the data (so there is space for only 1 RMPP header
there).

-- Hal