From: Sagi Grimberg <sa...@mellanox.com>
We'll need it later with the new CQ abstraction. also switch
login bufs to void pointers.
Signed-off-by: Sagi Grimberg <sa...@mellanox.com>
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/infiniband/ulp/iser/iscs
Remove struct rdma_iu and instead allocate the struct ib_rdma_wr array
early and fill out directly. This allows us to chain the WRs, and thus
archive both less lock contention on the HCA workqueue as well as much
simpler error handling.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
d
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/infiniband/ulp/srpt/ib_srpt.c | 327 +-
drivers/infiniband/ulp/srpt/ib_srpt.h | 28 +--
2 files changed, 88 insertions(+), 267 deletions(-)
diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c
b/d
This also moves recv completion handling from hardirq context into
softirq context.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/infiniband/ulp/srp/ib_srp.c | 173 +---
drivers/infiniband/ulp/srp/ib_srp.h | 7 +-
2 files changed, 86 inse
From: Sagi Grimberg <sa...@mellanox.com>
Use the new CQ abstraction to simplify completions in the iSER
initiator.
Signed-off-by: Sagi Grimberg <sa...@mellanox.com>
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/infiniband/ulp/iser/iscsi_iser.h | 72 +---
From: Sagi Grimberg <sa...@mellanox.com>
Nicer this way.
Signed-off-by: Sagi Grimberg <sa...@mellanox.com>
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/infiniband/ulp/iser/iscsi_iser.h | 6 ++
drivers/infiniband/ulp/iser/iser_initiator.c | 3 +--
driv
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
include/linux/irq_poll.h | 1 -
lib/irq_poll.c | 3 +--
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/linux/irq_poll.h b/include/linux/irq_poll.h
index c3145c7..ce9e1db 100644
--- a/include/linux/irq_poll.h
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
include/linux/irq_poll.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/linux/irq_poll.h b/include/linux/irq_poll.h
index ce9e1db..7527c03 100644
--- a/include/linux/irq_poll.h
+++ b/include/linux/irq_poll.h
@@ -7,9 +7,7 @@ t
There is no good reason to keep them apart, and this makes using the API
a bit simpler.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/scsi/be2iscsi/be_main.c | 6 ++
drivers/scsi/ipr.c | 3 +--
include/linux/irq_poll.h| 13 -
lib/irq_
There is no good reason to start out disabled - drivers can control if
the poll instance can be scheduled by simply not scheduling it yet.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/scsi/be2iscsi/be_main.c | 2 --
drivers/scsi/ipr.c | 2 --
lib/irq_
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
include/linux/irq_poll.h | 5 -
lib/irq_poll.c | 2 +-
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/include/linux/irq_poll.h b/include/linux/irq_poll.h
index 73d7c20..c3145c7 100644
--- a/include/linux/irq_
The new name is irq_poll as iopoll is already taken. Better suggestions
welcome.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
Documentation/kernel-per-CPU-kthreads.txt | 2 +-
block/Makefile| 2 +-
block/blk-iopoll.c
Looks good,
Reviewed-by: Christoph Hellwig <h...@lst.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Dec 03, 2015 at 04:20:50PM +, Liran Liss wrote:
> > From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
>
> > Subject: Re: [PATCH for-next V2 05/11] IB/core: Add rdma_network_type to
> > wc
> >
> > Bloating the WC with a field that's not really useful for the ULPs seems
> >
Hi Bart,
On Fri, Dec 04, 2015 at 03:08:15PM -0800, Bart Van Assche wrote:
> While preparing this patch series I noticed that none of the SCSI RDMA
> initiator drivers syncs RDMA buffers before performing RDMA. Does
> anyone know why something like the code below is not present in these
> drivers
Hi Doug,
not having any maintainer available for an extended time is a problem,
and we actually had long discussions about that at kernel summit, with
a clear hint with a cluebat from Linus that he'd prefer maintainer
teams. So I'd really love to know who was so ead set aginst them.
I
On Thu, Dec 03, 2015 at 10:46:10AM +0200, Sagi Grimberg wrote:
> >> If entries 2 and 3 could be merged dma_len for 2 would span 2 and 3,
> >> and then entry 3 would actually have the dma addr and len for entry 4.
>
> So what would be in the last entry {dma_addr, dma_len}? zeros?
>
> >>I'm
> How about the patch below ?
The patch looks good to me, but while we touch this area, how about
throwing in a few cosmetic fixes as well?
> - if (i && page_addr != dma_addr) {
> + if (i && (page_addr != dma_addr || last_page_off != 0)) {
> if
Bloating the WC with a field that's not really useful for the ULPs
seems pretty sad..
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 10, 2015 at 12:36:44PM +0200, Sagi Grimberg wrote:
> Any reply on this patchset?
Did we ever make progress on this?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Looks good,
Reviewed-by: Christoph Hellwig <h...@lst.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Looks good,
Reviewed-by: Christoph Hellwig <h...@lst.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Looks good,
Reviewed-by: Christoph Hellwig <h...@lst.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Dec 01, 2015 at 10:33:18AM -0500, Chuck Lever wrote:
> Oracle recently announced Sonoma, which is a SPARC CPU with
> an on-chip IB HCA. Oracle plans to publish an open-source
> GPL device driver that enables this HCA in Linux for SPARC.
> We???d eventually like to contribute it to the
On Tue, Dec 01, 2015 at 06:30:28PM +0200, Or Gerlitz wrote:
> Any reason on earth not to rebase your tree (== create new branch, move
> their the for-next tag) after an rc1 is out? how long does this take?
I'm not too worried about the base as there doesn't seem to be anything
pending for 4.5-rc
On Wed, Dec 02, 2015 at 01:59:38PM +0200, Sagi Grimberg wrote:
> >where nents is the number of entries in the sglist.
> >
>
> From Documentation/DMA_API.txt
>
>
> int
> dma_map_sg(struct device *dev, struct scatterlist *sg,
> int nents, enum dma_data_direction
On Tue, Nov 24, 2015 at 01:54:02PM -0800, santosh shilimkar wrote:
> As already indicated to Sagi [1], RDS IB FR support is work in
> progress and I was hoping to get it ready for 4.5. There are few
> issues we found with one of the HCA and hence the progress
> slowed down. Looking at where we
On Tue, Nov 24, 2015 at 09:24:51AM -0500, Chuck Lever wrote:
> There is only one (new) call site that needs it. I can simplify
> this patch as Sagi suggested before, but it seems silly to
> introduce the extra clutter of adding a gfp_t argument
> everywhere.
We a) generally try to pass the gfp_t
On Tue, Nov 24, 2015 at 09:08:21AM -0500, Chuck Lever wrote:
> Why don???t you fold my change into yours?
It's already included. Well, sort of - I have removed used of the
field, but forgot to remove the definition. I will update it.
--
To unsubscribe from this list: send the line "unsubscribe
On Mon, Nov 23, 2015 at 11:58:29AM -0700, Jason Gunthorpe wrote:
> > +#define IB_REG_LKEY(ib_reg_scope_t)0x
> > +#define IB_REG_RKEY(ib_reg_scope_t)0x0001
>
> Wrap in () just for convention?
Ok.
> Maybe
>
> unsigned int acc = ib_scope_to_access(scope);
> if
On Mon, Nov 23, 2015 at 05:17:30PM +0200, Sagi Grimberg wrote:
>
>> I send 1-9 out separately earlier :) The other two sit on top of them
>> and they are prep patches in a sense as they remove a lot of users
>> of struct ib_mr that i don't have to modify in patches 10 and 11.
>
> Still, patches
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
On Mon, Nov 23, 2015 at 11:03:42AM +0200, Sagi Grimberg wrote:
> Christoph,
>
>> This series removes huge chunks of code related to old memory
>> registration methods that we don't use anymore, and then simplifies the
>> current memory registration API
>
> Let's split out patches 10,11 from this
On Mon, Nov 23, 2015 at 12:35:44PM +0200, Sagi Grimberg wrote:
>
>> So Maybe we should have:
>> void ib_drain_qp(struct ib_qp *qp)
>
> Christoph suggested that this flushing would be taken care
> of by rdma_disconnect which sounds even better I think..
Note that will only work once we've
On Mon, Nov 23, 2015 at 07:53:04PM -0500, Chuck Lever wrote:
> > Wait, the REMOTE_WRITE is there to support iWARP, but it isn't
> > needed for IB or RoCE. Shouldn't this be updated to peek at those
> > new attributes to decide, instead of remaining unconditional?
>
> That???s coming in another
On Mon, Nov 23, 2015 at 05:14:14PM -0500, Chuck Lever wrote:
> In the current xprtrdma implementation, some memreg strategies
> implement ro_unmap synchronously (the MR is knocked down before the
> method returns) and some asynchonously (the MR will be knocked down
> and returned to the pool in
On Mon, Nov 23, 2015 at 07:57:42PM -0500, Tom Talpey wrote:
> On 11/23/2015 5:14 PM, Chuck Lever wrote:
> >FMR's ro_unmap method is already synchronous because ib_unmap_fmr()
> >is a synchronous verb. However, some improvements can be made here.
>
> I thought FMR support was about to be removed
> +struct svc_rdma_op_ctxt *svc_rdma_get_context_gfp(struct svcxprt_rdma *xprt,
> + gfp_t flags)
> +{
> + struct svc_rdma_op_ctxt *ctxt;
> +
> + ctxt = kmem_cache_alloc(svc_rdma_ctxt_cachep, flags);
> + if (!ctxt)
> + return
On Mon, Nov 23, 2015 at 10:09:05AM -0500, Chuck Lever wrote:
> Out of curiosity, why are you keeping the IB_ACCESS flags?
We'll still need them for all kinds of other use cases
(ib_get_dma_mr, userspace MRs, qp_access_flags).
> It would be more efficient for providers to convert the
> scope
On Mon, Nov 23, 2015 at 01:01:36PM -0700, Jason Gunthorpe wrote:
> Okay, having now read the whole thing, I think I see the flow now. I don't
> see any holes in the above, other than it is doing a bit more work
> than it needs in some edges cases because it doesn't know if the CQ is
> actually
On Sun, Nov 22, 2015 at 04:55:49PM +0200, Sagi Grimberg wrote:
> >>Also note that 4.4-rc prefer_fr=y register_always=n
> >>!register_always still blows up badly with XFS and ext4 due to
> >>data integrity errors.
>
> So the register_always=N makes bad things happen? if we register
> all the
On Sun, Nov 22, 2015 at 05:26:28PM +0200, Sagi Grimberg wrote:
> >No. register_always=Y is already broken in 4.3, but register_always=N is
> >now also broken in 4.4.
>
> OK, I'm confused so please let me understand slowly :)
>
> Your patch "ib_srp: initialize dma_length in srp_map_idb" solves
>
On Sun, Nov 22, 2015 at 05:53:43AM -0800, Christoph Hellwig wrote:
> To me this sounds like another argument to just allocate one FR
> per request and don't allow non-contiguous SGLs.
>
> Also note that 4.4-rc prefer_fr=y register_always=n
> !register_always still blows up
On Sun, Nov 22, 2015 at 11:51:13AM +0200, Sagi Grimberg wrote:
>
>> Hello Christoph,
>>
>> The comment about locality in the above quote is interesting. How about
>> modifying patch 2/9 as indicated below ? The modification below does not
>> change the behavior of this patch if ib_cq.w.cpu is not
On Sun, Nov 22, 2015 at 06:18:37PM +0530, Saurabh Sengar wrote:
> removing null dereference
How so? These are just sparse annotations, so I can't see how we'll
actually derference them. That beeing said they certainly are
incorrect..
--
To unsubscribe from this list: send the line "unsubscribe
And simplify the calling convention for full-memory registrations.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/staging/rdma/ehca/ehca_classes.h | 5 +-
drivers/staging/rdma/ehca/ehca_mrmw.c| 94 +++-
2 files changed, 46 insertions(+), 53 del
driver which is in the staging tree on it's way out can
actually return two values from it's thick firmware interface.
I doubt they ever were different, though.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/infiniband/core/uverbs_cmd.c | 8 +++---
d
Just pass and address/size pair instead of an ib_phys_buf array.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/infiniband/hw/nes/nes_cm.c| 10 +--
drivers/infiniband/hw/nes/nes_verbs.c | 140 --
drivers/infiniband/hw/nes/nes_verbs.h | 3
Instead of the confusing IB spec values provide a flags argument that
describes:
a) the operation we perform the memory registration for, and
b) if we want to access it for read or write purposes.
This helps to abstract out the IB vs iWarp differences as well.
Signed-off-by: Christoph
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/staging/rdma/amso1100/c2_provider.c | 67 ++---
1 file changed, 12 insertions(+), 55 deletions(-)
diff --git a/drivers/staging/rdma/amso1100/c2_provider.c
b/drivers/staging/rdma/amso1100/c2_provider.c
This functionality has no users and was only supported by the staged out
EHCA driver.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/infiniband/core/verbs.c | 7 -
drivers/staging/rdma/ehca/ehca_iverbs.h | 2 --
drivers/staging/rdma/ehca/ehca_main.c | 1 -
d
We have stopped using phys MRs in the kernel a while ago, so let's
remove all the cruft used to implement them.
Signed-off-by: Christoph Hellwig <h...@lst.de>
Reviewed-by: Steve Wise <sw...@opengridcomputing.com> [cxgb3, cxgb4]
---
drivers/infiniband/hw/cxgb3/iwch_mem.c
Remove the unused ib_allow_mw and ib_bind_mw functions, remove the
unused IB_WR_BIND_MW and IB_WC_BIND_MW opcodes and move ib_dealloc_mw
into the uverbs module.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
Documentation/infiniband/core_locking.txt | 2 -
drivers/infiniband/core/uv
Just IB_DEVICE_LOCAL_DMA_LKEY and IB_DEVICE_MEM_MGT_EXTENSIONS for now
as I'm most familar with those.
Signed-off-by: Christoph Hellwig <h...@lst.de>
Reviewed-by: Sagi Grimberg <sa...@mellanox.com>
Reviewed-By: Jason Gunthorpe <jguntho...@obsidianresearch.com>
---
include/rd
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
include/rdma/ib_verbs.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 1b2412b..81e047e 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -1128,11 +
Fold simplified versions of build_phys_page_list and
iwch_register_phys_mem into iwch_get_dma_wr now that no other callers
are left.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/infiniband/hw/cxgb3/iwch_mem.c | 71
drivers/infiniband/hw
This series removes huge chunks of code related to old memory
registration methods that we don't use anymore, and then simplifies the
current memory registration API
This expects my "IB: merge struct ib_device_attr into struct ib_device"
patch to be already applied.
Also available as a git tree:
On Wed, Nov 18, 2015 at 10:20:14AM -0800, Bart Van Assche wrote:
> Are you perhaps referring to the sysfs CPU mask that allows to control
> workqueue affinity ?
I think he is referring to the defintion of WQ_UNBOUND:
WQ_UNBOUND
Work items queued to an unbound wq are served by the
On Wed, Nov 18, 2015 at 08:32:59AM -0800, Bart Van Assche wrote:
> As you know events like a cable pull can cause some of the RDMA work
> requests to succeed and others to fail. It is essential that all RDMA work
> requests related to the same SCSI command have finished before the buffers
>
Looks good,
Reviewed-by: Christoph Hellwig <h...@lst.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Nov 19, 2015 at 09:12:20AM +0200, Or Gerlitz wrote:
> This is wrong assertion.
>
> Look on the code throughout the iser path done from iser_send_command, we
> allowed the command associated with the
> iscsi task to be IN, OUT, both or none, when we do all the dma-mapping,
> memory
> +enum {
> + CQ_CREATE_FLAGS_SUPPORTED = IB_CQ_FLAGS_TIMESTAMP_COMPLETION
> +};
How does userspace know the value of IB_CQ_FLAGS_TIMESTAMP_COMPLETION?
It's not defined in any UAPI header.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to
On Tue, Nov 17, 2015 at 11:38:48AM -0800, Bart Van Assche wrote:
> On 11/13/2015 05:46 AM, Christoph Hellwig wrote:
>> [ ... ]
>
> This patch contains two logical changes:
> - Conversion to the new CQ API.
> - Removal of the ib_srpt_compl thread.
>
> Had it b
On Wed, Nov 18, 2015 at 03:33:01PM +0200, Or Gerlitz wrote:
> Sagi, it works in TGT and AFAIR with the initiator too.
>
> Looking on this paper of Pete Wyckoff [1] I see that he says that
> few changes to the initiator were needed, not sure which.
Or, can you please stop it?
Fortunately
On Wed, Nov 18, 2015 at 01:32:19PM +0200, Sagi Grimberg wrote:
> Christoph,
>
> Given the discussion around this patch I think it would
> be a good idea remove it from the patchset since it's not
> mandatory for the CQ abstraction. I think that we should
> take it with Steve to come up with a
On Wed, Nov 18, 2015 at 03:58:48PM +0200, Or Gerlitz wrote:
> > Fortunately neither the iSER target or initiator ever support the
> > nightmare called bidi commands,
>
> I honestly don't know why you call it nightmare nor what make you
> make that strong assertion.
Beause I actually had to deal
On Tue, Nov 17, 2015 at 09:52:58AM -0800, Bart Van Assche wrote:
> On 11/13/2015 05:46 AM, Christoph Hellwig wrote:
>> + * context and does not ask from completion interrupts from the HCA.
>
> Should this perhaps be changed into "for" ?
On Tue, Nov 17, 2015 at 05:17:35PM -0800, Bart Van Assche wrote:
> Chaining RDMA requests is a great idea. But it seems to me that this patch
> is based on the assumption that posting multiple RDMA requests either
> succeeds as a whole or fails as a whole. Sorry but I'm not sure that the
>
On Tue, Nov 17, 2015 at 11:56:39AM -0800, Bart Van Assche wrote:
> On 11/13/2015 05:46 AM, Christoph Hellwig wrote:
>> +static void srp_inv_rkey_done(struct ib_cq *cq, struct ib_wc *wc)
>> +{
>> +srp_handle_qp_err(cq, wc, "INV RKEY");
>> +}
> >
>
On Tue, Nov 17, 2015 at 09:16:28AM -0800, Bart Van Assche wrote:
> How about renaming blk_iopoll into blk_poll ? That way the name still
> refers to the block layer. And although the current implementation performs
> polling from IRQ context future implementations maybe will allow polling
>
> + struct iser_cm_hdr rsp_hdr;
>
> memset(, 0, sizeof(struct rdma_conn_param));
> cp.initiator_depth = isert_conn->initiator_depth;
> cp.retry_count = 7;
> cp.rnr_retry_count = 7;
>
> + memset(_hdr, 0, sizeof(rsp_hdr));
> + rsp_hdr.flags =
> + if (dev_attr->device_cap_flags & IB_DEVICE_MEM_MGT_EXTENSIONS) {
> + iser_info("FastReg supported, using FastReg for
> registration\n");
> + device->reg_ops = _ops;
> + } else
> if (device->ib_device->alloc_fmr && device->ib_device->dealloc_fmr &&
Should
On Tue, Nov 17, 2015 at 12:04:03PM +0200, Or Gerlitz wrote:
> Also, do we refuse to queuecommand a bidi? where?
Or, can you please do the basic research first? Thanks! (Hint: check
how few drivers support bidi commands, and how it's enabled)
--
To unsubscribe from this list: send the line
Looks good,
Reviewed-by: Christoph Hellwig <h...@lst.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Nov 16, 2015 at 06:37:31PM +0200, Sagi Grimberg wrote:
> This patchset adds remote invalidation support to iser initiator and
> target. The support negotiation for this feature is based on IBTA
> annex 12 "Support for iSCSI Extensions for RDMA" carried in rdma_cm
> private data.
Oh, okay
On Tue, Nov 17, 2015 at 11:58:26AM +0200, Sagi Grimberg wrote:
> I don't know... Shouldn't it?
>
> I just copied include/scsi/srp.h and changed it...
Not a major issue, it just seemed a little strange to me.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of
Reviewed-by: Christoph Hellwig <h...@lst.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Nov 16, 2015 at 06:37:36PM +0200, Sagi Grimberg wrote:
> The iser RDMA_CM negotiation protocol is shared by
> the initiator and the target, so have a shared header
> for the defines and structure. Move relevant items from
> the initiator and target headers.
Nice!
But should a header that
On Mon, Nov 16, 2015 at 07:00:06PM +0200, Sagi Grimberg wrote:
>
>> Remove the unused ib_allow_mw and ib_bind_mw functions, remove the
>> unused IB_WR_BIND_MW and IB_WC_BIND_MW opcodes and move ib_dealloc_mw
>> into the uverbs module.
>>
>> Signed-off-b
Hi Bart,
the code in this area changed enough since 4.3 that it won't easily
apply. But a backport would still be very useful!
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Before we expose any new opcodes to userspace we need to actually
move the defintions of user visible opcodes to a uapi header. Without
that we're doomed to regularly break the ABI.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to
On Sun, Nov 15, 2015 at 11:48:08AM -0800, Bart Van Assche wrote:
> Did I understand correctly that page-aligned I/O works fine but I/O that is
> not aligned on a page boundary not ? Have you already had the time to verify
> whether the "IB/srp: Convert to new registration API" patch is the patch
>
On Sun, Nov 15, 2015 at 10:48:41AM +0200, Sagi Grimberg wrote:
> I have attempted to convert iser to use blk_iopoll in the past, however
> I've seen inconsistent performance and latency skews (comparing to
> tasklets iser is using today). This was manifested in IOPs test cases
> where I ran
On Sun, Nov 15, 2015 at 11:40:02AM +0200, Sagi Grimberg wrote:
> I doubt INT_MAX is useful as a budget in any use-case. it can easily
> hog the CPU. If the consumer is given access to poll a CQ, it must be
> able to provide some way to budget it. Why not expose a budget argument
> to the consumer?
FYI, I sent a patch for the zero S/G length issue. With this xfstests
does fine for ext4 and btrfs. With XFS I still run into corruption
warnings for the slab use after free poison pattern. I suspect that
issue might be related to uniqueue XFS I/O patterns. One thing that
might be related is
Fold simplified versions of build_phys_page_list and
iwch_register_phys_mem into iwch_get_dma_wr now that no other callers
are left.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/infiniband/hw/cxgb3/iwch_mem.c | 71 ---
drivers/infiniband/hw
Just pass and address/size pair instead of an ib_phys_buf array.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/infiniband/hw/nes/nes_cm.c| 10 +--
drivers/infiniband/hw/nes/nes_verbs.c | 140 --
drivers/infiniband/hw/nes/nes_verbs.h | 3
We have stopped using phys MRs in the kernel a while ago, so let's
remove all the cruft used to implement them.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/infiniband/hw/cxgb3/iwch_mem.c | 31 ---
drivers/infiniband/hw/cxgb3/iwch_provider.c | 69 --
drivers/infi
This functionality has no users and was only supported by the staged out
EHCA driver.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/infiniband/core/verbs.c | 7 -
drivers/staging/rdma/ehca/ehca_iverbs.h | 2 --
drivers/staging/rdma/ehca/ehca_main.c | 1 -
d
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/staging/rdma/amso1100/c2_provider.c | 67 ++---
1 file changed, 12 insertions(+), 55 deletions(-)
diff --git a/drivers/staging/rdma/amso1100/c2_provider.c
b/drivers/staging/rdma/amso1100/c2_provider.c
Remove the unused ib_allow_mw and ib_bind_mw functions, remove the
unused IB_WR_BIND_MW and IB_WC_BIND_MW opcodes and move ib_dealloc_mw
into the uverbs module.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
Documentation/infiniband/core_locking.txt | 2 -
drivers/infiniband/core/uv
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
include/rdma/ib_verbs.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 0bbbd4b..3253563 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -1145,11 +
And simplify the calling convention for full-memory registrations.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/staging/rdma/ehca/ehca_classes.h | 5 +-
drivers/staging/rdma/ehca/ehca_mrmw.c| 94 +++-
2 files changed, 46 insertions(+), 53 del
This series removes huge chunks of code related to old memory
registration methods that we don't use anymore.
This expects my "IB: merge struct ib_device_attr into struct ib_device"
patch to be already applied.
Also available as a git tree:
Without this sg_dma_len will return 0 on architectures tha have
the dma_length field.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/infiniband/ulp/srp/ib_srp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
b/drivers/infiniband/u
On Fri, Nov 13, 2015 at 05:23:39PM +0200, Or Gerlitz wrote:
> On Fri, Nov 13, 2015 at 3:46 PM, Christoph Hellwig <h...@lst.de> wrote:
> > The new name is irq_poll as iopoll is already taken. Better suggestions
> > welcome.
>
> Sagi (or Christoph if you can address that
On Fri, Nov 13, 2015 at 11:19:24AM -0800, Bart Van Assche wrote:
> On 11/13/2015 05:46 AM, Christoph Hellwig wrote:
>> The new name is irq_poll as iopoll is already taken. Better suggestions
>> welcome.
>
> Hello Christoph,
>
> Would it be possible to provide more b
On Fri, Nov 13, 2015 at 11:25:13AM -0700, Jason Gunthorpe wrote:
> For instance, like this, not fulling draining the cq and then doing:
>
> > + completed = __ib_process_cq(cq, budget);
> > + if (completed < budget) {
> > + irq_poll_complete(>iop);
> > + if
On Fri, Nov 13, 2015 at 10:16:04AM -0600, Steve Wise wrote:
> So how can we do this for iwarp? It seems like all that might be needed is
> to modify the QP state to idle, retrying until it succeeds:
>
>If the QP is transitioning to the Error state, or has not yet
>finished flushing the
On Fri, Nov 13, 2015 at 03:06:36PM -0700, Jason Gunthorpe wrote:
> Looking at that thread and then at the patch a bit more..
>
> +void ib_process_cq_direct(struct ib_cq *cq)
> [..]
> + __ib_process_cq(cq, INT_MAX);
>
> INT_MAX is not enough, it needs to loop.
> This is missing a
101 - 200 of 423 matches
Mail list logo
