> -----Original Message----- > From: linux-rdma-owner@xxxxxxxxxxxxxxx [mailto:linux-rdma-owner@xxxxxxxxxxxxxxx] On Behalf Of Chuck Lever > Sent: Tuesday, June 30, 2015 9:42 AM > To: Steve Wise > Cc: Or Gerlitz; 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 Jun 30, 2015, at 10:29 AM, Steve Wise <swise@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > >> -----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. > > I was planning to look at this more closely soon, but if you > have patches I'd happily consider them, or you can just point > me to what needs to be changed and I can put it together for 4.3. > Thanks. I suggest you hold off on NFSRDMA changes until we get closure on the new core services. Once it stabilizes, I'll ping ya. (and I'll CC you on subsequent versions of this). Stevo -- 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
