In addition to passing the hdr_len and data_len to ib_create_send_mad: rmpp_mad->rmpp_hdr.paylen_newwin = cpu_to_be32(hdr_len -
offsetof(struct ib_rmpp_mad, data) + data_len);
That's not the "real" payload length that would go into the packet; just
one segment's worth of class header. Correct ?
If the above is correct, I'm not sure the actual payload lengths in the DATA packets are correct. I also see the padding on the last segment of a multipacket send not cleared (I integrated the part of your patch relating to the pad calculation).
Running grmpp and using madeye to check the packets, I ran 3 tests:
user-data size payload 1st in segment payload in last segment 1200 1320 (220x6) 124 50 54 54 580 660 (220x3) 152
For multi-packet segments, I think that the payload in the 1st segment will always be a multiple of 220 bytes (256 - sizeof common MAD header - sizeof RMPP header). For the tests that I ran, these appear to be correct.
Since grmpp uses vendor MADs, it can transfer 216 bytes of user-data per segment. Using the 580 example, the data is segmented into 216 + 216 + 148 bytes. The payload in the last segment includes the extra 4 byte vendor specific header. Likewise, 1200 = 216 x 5 + 120, with an extra 4 bytes added for the header.
I haven't looked at why the data isn't cleared yet, but will do so next. The memory allocations in create_send_mad look right to me...
- Sean
_______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
