ox.com; linux-rdma@vger.kernel.org;
> jguntho...@obsidianresearch.com; infinipath;
> e...@mellanox.com; ogerl...@mellanox.com
> Subject: Re: [PATCH V2 3/5] RDMA/core: transport-independent access flags
>
> On 7/2/2015 4:17 PM, Steve Wise wrote:
> > On 7/2/2015 1:22 AM, Sagi Grimberg
On 7/2/2015 4:17 PM, Steve Wise wrote:
On 7/2/2015 1:22 AM, Sagi Grimberg wrote:
On 6/30/2015 8:10 PM, Hefty, Sean wrote:
I suggest to start consolidating to ib_create_mr() that receives an
extensible ib_mr_init_attr and additional attributes can be mr_roles
and mr_attrs.
I think this makes s
On 7/2/2015 1:22 AM, Sagi Grimberg wrote:
On 6/30/2015 8:10 PM, Hefty, Sean wrote:
I suggest to start consolidating to ib_create_mr() that receives an
extensible ib_mr_init_attr and additional attributes can be mr_roles
and mr_attrs.
I think this makes sense, but does it really help?
If the en
On 6/30/2015 8:10 PM, Hefty, Sean wrote:
I suggest to start consolidating to ib_create_mr() that receives an
extensible ib_mr_init_attr and additional attributes can be mr_roles
and mr_attrs.
I think this makes sense, but does it really help?
If the end result is that the app and providers basi
On 6/30/2015 7:42 PM, Jason Gunthorpe wrote:
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.
It would be excellent
.@mellanox.com; ogerl...@mellanox.com; sean.he...@intel.com
> Subject: Re: [PATCH V2 3/5] RDMA/core: transport-independent access flags
>
> On Mon, Jun 29, 2015 at 04:36:18PM -0500, Steve Wise wrote:
> > +int rdma_device_access_flags(struct ib_pd *pd, int roles, int attrs)
>
> I suggest to start consolidating to ib_create_mr() that receives an
> extensible ib_mr_init_attr and additional attributes can be mr_roles
> and mr_attrs.
I think this makes sense, but does it really help? If the end result is that
the app and providers basically end up switching on mr_attr::t
> 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.
It would be excellent if this series actually went through and g
On Mon, Jun 29, 2015 at 04:36:18PM -0500, Steve Wise wrote:
> +int rdma_device_access_flags(struct ib_pd *pd, int roles, int attrs)
> +{
> + int access_flags = attrs;
No RDMA_MRR_SEND ?
> + if (roles & RDMA_MRR_RECV)
> + access_flags |= IB_ACCESS_LOCAL_WRITE;
> +
> + if (r
com;
> linux-rdma@vger.kernel.org;
> jguntho...@obsidianresearch.com; infinip...@intel.com; e...@mellanox.com;
> sean.he...@intel.com
> Subject: Re: [PATCH V2 3/5] RDMA/core: transport-independent access flags
>
>
> On Jun 30, 2015, at 10:29 AM, Steve Wise wrote:
>
> >
&
; sa...@mellanox.com;
>> linux-rdma@vger.kernel.org; jguntho...@obsidianresearch.com;
>> infinip...@intel.com; e...@mellanox.com; sean.he...@intel.com
>> Subject: Re: [PATCH V2 3/5] RDMA/core: transport-independent access flags
>>
>> On 6/30/2015 12:36 AM, Steve Wise wrot
...@intel.com;
> e...@mellanox.com; ogerl...@mellanox.com; sean.he...@intel.com
> 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
rch.com;
> infinip...@intel.com; e...@mellanox.com; sean.he...@intel.com
> 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 r
...@intel.com;
> e...@mellanox.com; ogerl...@mellanox.com; sean.he...@intel.com
> Subject: Re: [PATCH V2 3/5] RDMA/core: transport-independent access flags
>
> On 30/06/2015 00:36, Steve Wise wrote:
> > /**
> > + * rdma_mr_roles - possible roles an RDMA MR will be used f
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 appr
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 appr
On 30/06/2015 00:36, Steve Wise wrote:
> /**
> + * rdma_mr_roles - possible roles an RDMA MR will be used for
> + *
> + * This allows a transport independent RDMA application to
> + * create MRs that are usable for all the desired roles w/o
> + * having to understand which access rights are needed
17 matches
Mail list logo
