Re: [PATCH 1/7] libibumad: Provide MAD definitions with libibumad

[Hal Rosenstock <hal-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>]

On 2/20/2013 12:42 PM, Ira Weiny wrote:
> On Wed, 20 Feb 2013 11:39:53 -0500
> Hal Rosenstock <hal-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html