On 2/20/2013 12:42 PM, Ira Weiny wrote: > On Wed, 20 Feb 2013 11:39:53 -0500 > Hal Rosenstock <[email protected]> wrote: > >> On 2/20/2013 11:29 AM, Hefty, Sean wrote: >>>> I need to check the kernel code, but I believe that the RMPP header is >>>> exposed. >>> >>> I looked at copy_recv_mad(), and it copies the entire 256-byte MAD to user >>> space, which includes any RMPP header, followed by any additional segmented >>> data. So most of the RMPP definitions are relevant, the exceptions >>> possibly being UMAD_RMPP_TYPE_[ACK | STOP | ABORT]. IMO - I would keep >>> those for completeness. >> >> Yes but how much of header is relevant when it's a multipacket RMPP MAD >> message ? My concern is that it may be confusing as to validity/use of >> certain RMPP fields, etc. >> > > IMO the confusion can be overcome by documenting that fact that libibumad > coalesces the multipacket RMPP response into one buffer returned by umad_recv > as well as how it is done. This is where the confusion lies.
Would you generate a patch that clarifies this issue for both the receive and send sides ? Thanks. -- Hal > If you do accept the RMPP defines I have a subsequent patch for the *_str > functions for them. > > Ira > >> -- Hal >> >>> - Sean >>> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in >> the body of a message to [email protected] >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
