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 _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
