Re: [PATCH RFC] RDMA/core: add rdma_get_dma_mr()

[Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>]

On 6/25/2015 5:37 PM, Hefty, Sean wrote:
>> +enum rdma_mr_roles {
> I would drop naming the enum - it shouldn't be used, as the values are bit flags.

ok.

>> +	RDMA_MRR_RECV			= 1,
>> +	RDMA_MRR_SEND			= (1<<1),
>> +	RDMA_MRR_READ_SOURCE		= (1<<2),
>> +	RDMA_MRR_READ_SINK		= (1<<3),
>> +	RDMA_MRR_WRITE_SOURCE		= (1<<4),
>> +	RDMA_MRR_WRITE_SINK		= (1<<5),
>> +	RDMA_MRR_ATOMIC			= (1<<6),
>> +	RDMA_MRR_MW_BIND		= (1<<7),
>> +	RDMA_MRR_ZERO_BASED		= (1<<8),
> There's 'something' different about this role that cause me hesitation.  Maybe that it's dependent on other roles being set to be useful?  I'm not sure.
>
> Maybe we need both roles and registration flags, with this declared as a flag?
>
>> +	RDMA_MRR_ACCESS_ON_DEMAND	= (1<<9),
> This one is even more different, as it doesn't impact how the MR interacts with the interfaces, or change how the application uses the MR.  This is really a hint to the provider regarding the selection of different implementation flows.

How about roles and attributes?  ZERO_BASED and ACCESS_ON_DEMAND would 
be attributes and the rest roles.

--
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