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
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 that adds iwarp-only FRMR IO
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
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 that adds iwarp-only
...@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?
Hi Steve,
This is taking longer than I expected, the changes needed
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; 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, Sagi Grimberg wrote:
On 7/24/2015 7:18 PM, Steve Wise
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
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) to
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
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 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
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
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
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 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
This is in preparation for adding new FRMR-only IO handlers
for devices that support FRMR and not PI.
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/ulp/isert/ib_isert.c | 28 ++--
1 files changed, 14 insertions(+), 14 deletions(-)
diff
17 matches
Mail list logo
