[openib-general] RE: [PATCH 3 of 3] mad: large RMPP support, Round 2

[Sean Hefty]

Jack Morgenstein wrote:
> Either way is OK by me.  Note that ib_create_send_mad does allocate the "base"
> MAD with kzalloc.  Its just the RMPP segments that are allocated with kmalloc 
> and are not initially cleared.

I have a patch that updates the comments.  The comments states that the code 
clears the MAD headers, formats any RMPP header, and clears any padding.

> I just thought that by returning the segment size in the procedure call, we 
> preserve the option to easily support multiple segment sizes within a single
> RMPP message.  However, if you think that we will never need such an option,
> I don't object to exposing the segment size in the ib_mad_send_buf structure.

Hmm... this makes sense.  What I have done currently is add hdr_len, seg_count, 
and seg_size fields to ib_mad_send_buf.  The original MAD code didn't require 
that the user allocate a MAD using a helper function.  That has since been 
changed by adding ib_mad_send_buf, and the code wasn't ever cleaned up as a 
result of this.

Since users must call ib_create_send_mad(), there are a few places in the code 
where we can be more efficient when handling RMPP, and eliminate some duplicated 
   RMPP information.  For example, by saving the hdr_len and seg_count, we avoid 
having to recalculate these later, and we can format the RMPP paylen to the 
correct value, rather than the more confusing value that it's set to now.

Reporting the segment size when retrieving a segment may make sense.  I'm not 
sure if we'll ever support variable sized segments, since doing so complicates 
the RMPP code.

- Sean