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
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/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 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 l
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
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 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 reaso
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
> > 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
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
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
> >
>
> Perhaps then we should go with my version t
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 w
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
17 matches
Mail list logo
