Nic is silent...
Sagi, do you have an ETA on when you can have the recode ready for detailed
review and test? If we can't make linux-4.3, can we be early in staging it for
linux-4.4?
Hi Steve,
I have something, but its not remotely close to be submission ready.
This ended up being a rewrite
> Hey Sagi, how is this coming along? How can I help?
>
> >>>
> >>> Hi Steve,
> >>>
> >>> This is taking longer than I expected, the changes needed seem
> >>> pretty extensive throughout the IO path. I don't think it will be ready
> >>> for 4.3
> >>>
> >>
> >> Perhaps then we should go w
On 8/6/2015 12:23 AM, Steve Wise wrote:
Hey Sagi, how is this coming along? How can I help?
Hi Steve,
This is taking longer than I expected, the changes needed seem
pretty extensive throughout the IO path. I don't think it will be ready
for 4.3
Perhaps then we should go with my versio
> >
> > > Hey Sagi, how is this coming along? How can I help?
> > >
> >
> > Hi Steve,
> >
> > This is taking longer than I expected, the changes needed seem
> > pretty extensive throughout the IO path. I don't think it will be ready
> > for 4.3
> >
>
> Perhaps then we should go with my version t
er.kernel.org;
> e...@mellanox.com; target-de...@vger.kernel.org; linux-...@vger.kernel.org;
> bfie...@fieldses.org
> Subject: Re: [PATCH V6 6/9] isert: Rename IO functions to more descriptive
> names
>
> > Hey Sagi, how is this coming along? How can I help?
> >
>
> H
Hey Sagi, how is this coming along? How can I help?
Hi Steve,
This is taking longer than I expected, the changes needed seem
pretty extensive throughout the IO path. I don't think it will be ready
for 4.3
I'll try to send you soon a preliminary version to play with.
Acceptable?
--
To unsub
> > Steve,
> >
> > I've given this some thought and I think we should avoid splitting
> > logic from PI and iWARP. The reason (other than code duplication) is
> > that currently the iser target support only up to 1MB IOs. I have some
> > code (not done yet) to support larger IOs by using multiple
mellanox.com;
> r...@mellanox.com; linux-rdma@vger.kernel.org;
> e...@mellanox.com; target-de...@vger.kernel.org; linux-...@vger.kernel.org;
> bfie...@fieldses.org
> Subject: Re: [PATCH V6 6/9] isert: Rename IO functions to more descriptive
> names
>
> On 7/26/2015 5:08 AM, Sag
On 7/26/2015 5:08 AM, Sagi Grimberg wrote:
On 7/24/2015 7:18 PM, Steve Wise wrote:
This is in preparation for adding new FRMR-only IO handlers
for devices that support FRMR and not PI.
Steve,
I've given this some thought and I think we should avoid splitting
logic from PI and iWARP. The reaso
On 7/26/2015 12:40 PM, Sagi Grimberg wrote:
Ideally, the post contains a chain of all 4 registrations and the
rdma_read (and an opportunistic good scsi response).
Just to be clear: This example is for IB only, correct? IW would
require rkeys with REMOTE_WRITE and 4 read wrs.
My assumption
Ideally, the post contains a chain of all 4 registrations and the
rdma_read (and an opportunistic good scsi response).
Just to be clear: This example is for IB only, correct? IW would
require rkeys with REMOTE_WRITE and 4 read wrs.
My assumption is that it would depend on max_sge_rd.
IB on
On 7/26/2015 6:00 AM, Sagi Grimberg wrote:
On 7/26/2015 1:43 PM, Christoph Hellwig wrote:
On Sun, Jul 26, 2015 at 01:08:16PM +0300, Sagi Grimberg wrote:
I've given this some thought and I think we should avoid splitting
logic from PI and iWARP. The reason (other than code duplication) is
that c
On 7/26/2015 6:53 PM, Christoph Hellwig wrote:
On Sun, Jul 26, 2015 at 02:00:51PM +0300, Sagi Grimberg wrote:
On the wire iser sends a single rkey, but the target is allowed to
transfer the data however it wants to.
So you're trying to get above the limit of a single RDMA READ, not
above the l
On Sun, Jul 26, 2015 at 02:00:51PM +0300, Sagi Grimberg wrote:
> On the wire iser sends a single rkey, but the target is allowed to
> transfer the data however it wants to.
So you're trying to get above the limit of a single RDMA READ, not
above the limit for memory registration in the initiator?
On 7/26/2015 1:43 PM, Christoph Hellwig wrote:
On Sun, Jul 26, 2015 at 01:08:16PM +0300, Sagi Grimberg wrote:
I've given this some thought and I think we should avoid splitting
logic from PI and iWARP. The reason (other than code duplication) is
that currently the iser target support only up to
On Sun, Jul 26, 2015 at 01:08:16PM +0300, Sagi Grimberg wrote:
> I've given this some thought and I think we should avoid splitting
> logic from PI and iWARP. The reason (other than code duplication) is
> that currently the iser target support only up to 1MB IOs. I have some
> code (not done yet) t
On 7/24/2015 7:18 PM, Steve Wise wrote:
This is in preparation for adding new FRMR-only IO handlers
for devices that support FRMR and not PI.
Steve,
I've given this some thought and I think we should avoid splitting
logic from PI and iWARP. The reason (other than code duplication) is
that curr
This is in preparation for adding new FRMR-only IO handlers
for devices that support FRMR and not PI.
Signed-off-by: Steve Wise
---
drivers/infiniband/ulp/isert/ib_isert.c | 28 ++--
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/infiniband/ul
18 matches
Mail list logo