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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
