ULPs are *already* using the same registrations for both local and
remote access.
Where? Out of tree?
I haven't found anything in-tree for sure.
We have that in iSER.
iSCSI allows a FirstBurst functionality and iSER as an iSCSI
transport is required to support that.
The FirstBurst is
On Wed, Jan 06, 2016 at 05:10:06PM +0200, Sagi Grimberg wrote:
>
> >>>ULPs are *already* using the same registrations for both local and
> >>>remote access.
> >>
> >>Where? Out of tree?
> >
> >I haven't found anything in-tree for sure.
>
> We have that in iSER.
>
> iSCSI allows a FirstBurst
On Fri, Dec 25, 2015 at 06:46:07PM +0200, Liran Liss wrote:
> > From: Jason Gunthorpe
>
> > > >fill mr->key by the lkey or rkey based on that and everything will
> > > >work fine.
> > >
> > > But the ULP *can* register a memory buffer with local and remote
> > >
On Tue, Jan 05, 2016 at 10:46:36AM -0700, Jason Gunthorpe wrote:
> > ULPs are *already* using the same registrations for both local and
> > remote access.
>
> Where? Out of tree?
I haven't found anything in-tree for sure.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma"
> From: Jason Gunthorpe
> > >fill mr->key by the lkey or rkey based on that and everything will
> > >work fine.
> >
> > But the ULP *can* register a memory buffer with local and remote
> > access permissions.
> Not in the new API.
>
> If a ULP ever comes along
On Tue, Dec 22, 2015 at 06:58:14PM +0200, Sagi Grimberg wrote:
>
> >The ULP decides if this MR is going to be used as a lkey or rkey
> >by passing IB_REG_LKEY or IB_REG_RKEY. The HCA driver will then
> >fill mr->key by the lkey or rkey based on that and everything will
> >work fine.
>
> But the
Hi Christoph,
While IB supports the notion of returning separate local and remote keys
from a memory registration, the iWarp spec doesn't and neither does any
of our in-tree HCA drivers [1] nor consumers. Consolidate the in-kernel
API to provide only a single key and make everyones life
On Tue, Dec 22, 2015 at 11:17:54AM +0200, Sagi Grimberg wrote:
> What makes me worried here is that the IB/RoCE specification really
> defines different keys for local and remote access. I'm less concerned
> about our consumers but more about our providers. We keep seeing new
> providers come
The ULP decides if this MR is going to be used as a lkey or rkey
by passing IB_REG_LKEY or IB_REG_RKEY. The HCA driver will then
fill mr->key by the lkey or rkey based on that and everything will
work fine.
But the ULP *can* register a memory buffer with local and remote
access permissions.
On Tue, Dec 22, 2015 at 03:50:12PM +0200, Sagi Grimberg wrote:
> This is why I said that the problem here is not the ULPs. But if a new
> HW comes along with distinction between rkeys and lkeys it will have a
> problem. For example a HW allocates two different keys, rkey and lkey.
> And, it
On 22/12/2015 15:13, Christoph Hellwig wrote:
On Tue, Dec 22, 2015 at 11:17:54AM +0200, Sagi Grimberg wrote:
What makes me worried here is that the IB/RoCE specification really
defines different keys for local and remote access. I'm less concerned
about our consumers but more about our
On Sun, Nov 22, 2015 at 06:46:48PM +0100, Christoph Hellwig wrote:
> While IB supports the notion of returning separate local and remote keys
> from a memory registration, the iWarp spec doesn't and neither does any
> of our in-tree HCA drivers [1] nor consumers. Consolidate the in-kernel
> API
On Mon, Nov 23, 2015 at 12:41:24PM -0700, Jason Gunthorpe wrote:
> I like this too, but, I'm a little worried this makes the API more
> confusing - ideally, we'd get rid of all the IB_ACCESS stuff from
> within the kernel completely.
That's my plan - at least for MRs. The only place still using
While IB supports the notion of returning separate local and remote keys
from a memory registration, the iWarp spec doesn't and neither does any
of our in-tree HCA drivers [1] nor consumers. Consolidate the in-kernel
API to provide only a single key and make everyones life easier.
[1] the EHCA
14 matches
Mail list logo