[openib-general] Re: FW: [PATCH 1 of 3] mad: large RMPP support
Sean Hefty
sean.hefty at intel.com
Thu Feb 9 20:50:32 PST 2006
>> The latest idea that I was suggesting was to separate the MAD header from
>> the data segments for multi-segment/RMPP active MADs. Let *mad reference
>> the header, and rmpp_list reference all data segments. Non-RMPP MADs would
>> use *mad to reference the entire buffer. For an RMPP MAD (one with RMPP
>> active) that fits into a single segment, I can go either way.
>
>What problem would this change address?
>From the original patch, this addresses walking through the list multiple times.
A user needs to be able to walk through all data segments in order to copy the
data. It easier to me to do:
For each segment
Copy the segment
Versus:
Copy the first segment
For each segment > 1
Copy the segment
The RMPP code would also be able to treat all segments equally. It can use
last_ack and last_sent pointers to track its location. On a timeout, it simply
resends starting at last_ack, versus checking to see if the timeout occurred on
the first segment or some later segment. Likewise an ACK would simply move the
last_ack pointer forward, versus needing the check.
My assumption is that this would result in a simpler implementation. From
within the kernel, it seems like it would. I don't know if there's easier or
more efficient approach given the user_mad implementation, hence my question
regarding whether kernel modules would need to send multi-segment RMPP MADs.
If not, it's entirely possible that we may find that what works well for
handling MADs coming down from userspace may not be the most efficient
implementation from RMPP's viewpoint. In any case, I think it's important to
see multiple implementation possibilities, so that others can be considered if
the implementation of one starts getting ugly.
- Sean
More information about the general
mailing list