> -----Original Message----- > From: Or Gerlitz [mailto:ogerlitz@xxxxxxxxxxxx] > Sent: Tuesday, June 30, 2015 4:04 AM > To: Steve Wise; Chuck Lever > Cc: dledford@xxxxxxxxxx; roid@xxxxxxxxxxxx; sagig@xxxxxxxxxxxx; linux-rdma@xxxxxxxxxxxxxxx; jgunthorpe@xxxxxxxxxxxxxxxxxxxx; > infinipath@xxxxxxxxx; eli@xxxxxxxxxxxx; sean.hefty@xxxxxxxxx > Subject: Re: [PATCH V2 3/5] RDMA/core: transport-independent access flags > > On 6/30/2015 12:36 AM, Steve Wise wrote: > > The semantics for MR access flags are not consistent across RDMA > > protocols. So rather than have applications try and glean what they > > need, have them pass in the intended roles and attributes for the MR to > > be allocated and let the RDMA core select the appropriate access flags > > given the roles, attributes, and device capabilities. > > wait, we have NFSoRDMA (net/sunrpc/xprtrdma/*) in the kernel for years > and it works on top of both IB/RoCE and iWARP.I know they have there 5-6 > memory registration methods.. but if we stick to their mode that uses > fast registration ala your upstream commit 0f7ec3 "RDMA/core: Add memory > management extensions support" -- what's missing or how come it work > w/o the enhancement suggested here?Added Chuck. NFSRDMA currently checks the transport type to decide how to set the access flags for memory registration. With the new services exported in this series, we can change/simplify NFSRDMA to not have to know the transport type. -- 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
