* [PATCH v2 0/3] new ib_drain_qp() API @ 2016-02-08 22:14 Steve Wise [not found] ` <cover.1454969695.git.swise-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org> 0 siblings, 1 reply; 24+ messages in thread From: Steve Wise @ 2016-02-08 22:14 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA; +Cc: bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ This series creates a new helper API for draining a queue pair. It is a rework of an original patch created by Christoph Hellwig as part of the CQ API rework and was dropped to be resubmitted by me with iw_cxgb4 support. Original thread: http://www.spinics.net/lists/linux-rdma/msg30296.html Changes since v1: - added comments to the ib_drain_qp() function header specifying the consumer requirements - in __ib_drain_qp(), if the ib_post_send() fails, still wait for the recv wr to drain since we already posted it. - CC the SRP maintainer, bart.vanassche-XdAiOPVOjtvowKkBSvOlow@public.gmane.org --- Steve Wise (3): IB: new common API for draining a queue pair iw_cxgb4: add drain_qp function IB/srp: use ib_drain_qp() drivers/infiniband/core/verbs.c | 77 ++++++++++++++++++++++++++++++++++ drivers/infiniband/hw/cxgb4/cq.c | 6 ++- drivers/infiniband/hw/cxgb4/iw_cxgb4.h | 2 + drivers/infiniband/hw/cxgb4/provider.c | 1 + drivers/infiniband/hw/cxgb4/qp.c | 8 ++++ drivers/infiniband/ulp/srp/ib_srp.c | 45 ++++---------------- include/rdma/ib_verbs.h | 2 + 7 files changed, 102 insertions(+), 39 deletions(-) -- 2.7.0 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <cover.1454969695.git.swise-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>]
* [PATCH 2/3] iw_cxgb4: add drain_qp function [not found] ` <cover.1454969695.git.swise-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org> @ 2016-01-14 18:24 ` Steve Wise 2016-01-27 20:09 ` [PATCH 3/3] IB/srp: use ib_drain_qp() Steve Wise ` (2 subsequent siblings) 3 siblings, 0 replies; 24+ messages in thread From: Steve Wise @ 2016-01-14 18:24 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA; +Cc: bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ Add a completion object, named qp_drained, to the c4iw_qp struct. This completion object is signaled when the last CQE is drained from the CQs for the QP. Add c4iw_dain_qp() to block until qp_drained is completed. Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org> --- drivers/infiniband/hw/cxgb4/cq.c | 6 +++++- drivers/infiniband/hw/cxgb4/iw_cxgb4.h | 2 ++ drivers/infiniband/hw/cxgb4/provider.c | 1 + drivers/infiniband/hw/cxgb4/qp.c | 8 ++++++++ 4 files changed, 16 insertions(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/cxgb4/cq.c b/drivers/infiniband/hw/cxgb4/cq.c index cf21df4..6fdcf78 100644 --- a/drivers/infiniband/hw/cxgb4/cq.c +++ b/drivers/infiniband/hw/cxgb4/cq.c @@ -815,8 +815,12 @@ static int c4iw_poll_cq_one(struct c4iw_cq *chp, struct ib_wc *wc) } } out: - if (wq) + if (wq) { + if (unlikely(qhp->attr.state != C4IW_QP_STATE_RTS && + t4_sq_empty(wq) && t4_rq_empty(wq))) + complete(&qhp->qp_drained); spin_unlock(&qhp->lock); + } return ret; } diff --git a/drivers/infiniband/hw/cxgb4/iw_cxgb4.h b/drivers/infiniband/hw/cxgb4/iw_cxgb4.h index fb2de75..fdb9d9a 100644 --- a/drivers/infiniband/hw/cxgb4/iw_cxgb4.h +++ b/drivers/infiniband/hw/cxgb4/iw_cxgb4.h @@ -476,6 +476,7 @@ struct c4iw_qp { wait_queue_head_t wait; struct timer_list timer; int sq_sig_all; + struct completion qp_drained; }; static inline struct c4iw_qp *to_c4iw_qp(struct ib_qp *ibqp) @@ -1016,6 +1017,7 @@ extern int c4iw_wr_log; extern int db_fc_threshold; extern int db_coalescing_threshold; extern int use_dsgl; +void c4iw_drain_qp(struct ib_qp *qp); #endif diff --git a/drivers/infiniband/hw/cxgb4/provider.c b/drivers/infiniband/hw/cxgb4/provider.c index ec04272..0ab942f 100644 --- a/drivers/infiniband/hw/cxgb4/provider.c +++ b/drivers/infiniband/hw/cxgb4/provider.c @@ -564,6 +564,7 @@ int c4iw_register_device(struct c4iw_dev *dev) dev->ibdev.get_protocol_stats = c4iw_get_mib; dev->ibdev.uverbs_abi_ver = C4IW_UVERBS_ABI_VERSION; dev->ibdev.get_port_immutable = c4iw_port_immutable; + dev->ibdev.drain_qp = c4iw_drain_qp; dev->ibdev.iwcm = kmalloc(sizeof(struct iw_cm_verbs), GFP_KERNEL); if (!dev->ibdev.iwcm) diff --git a/drivers/infiniband/hw/cxgb4/qp.c b/drivers/infiniband/hw/cxgb4/qp.c index e99345e..2e70c01 100644 --- a/drivers/infiniband/hw/cxgb4/qp.c +++ b/drivers/infiniband/hw/cxgb4/qp.c @@ -1697,6 +1697,7 @@ struct ib_qp *c4iw_create_qp(struct ib_pd *pd, struct ib_qp_init_attr *attrs, qhp->attr.max_ird = 0; qhp->sq_sig_all = attrs->sq_sig_type == IB_SIGNAL_ALL_WR; spin_lock_init(&qhp->lock); + init_completion(&qhp->qp_drained); mutex_init(&qhp->mutex); init_waitqueue_head(&qhp->wait); atomic_set(&qhp->refcnt, 1); @@ -1888,3 +1889,10 @@ int c4iw_ib_query_qp(struct ib_qp *ibqp, struct ib_qp_attr *attr, init_attr->sq_sig_type = qhp->sq_sig_all ? IB_SIGNAL_ALL_WR : 0; return 0; } + +void c4iw_drain_qp(struct ib_qp *ibqp) +{ + struct c4iw_qp *qp = to_c4iw_qp(ibqp); + + wait_for_completion(&qp->qp_drained); +} -- 2.7.0 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH 3/3] IB/srp: use ib_drain_qp() [not found] ` <cover.1454969695.git.swise-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org> 2016-01-14 18:24 ` [PATCH 2/3] iw_cxgb4: add drain_qp function Steve Wise @ 2016-01-27 20:09 ` Steve Wise 2016-02-05 21:13 ` [PATCH 1/3] IB: new common API for draining a queue pair Steve Wise 2016-02-09 20:04 ` [PATCH v2 0/3] new ib_drain_qp() API Steve Wise 3 siblings, 0 replies; 24+ messages in thread From: Steve Wise @ 2016-01-27 20:09 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA; +Cc: bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org> --- drivers/infiniband/ulp/srp/ib_srp.c | 45 ++++++------------------------------- 1 file changed, 7 insertions(+), 38 deletions(-) diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c index 03022f6..95670ae 100644 --- a/drivers/infiniband/ulp/srp/ib_srp.c +++ b/drivers/infiniband/ulp/srp/ib_srp.c @@ -446,49 +446,17 @@ static struct srp_fr_pool *srp_alloc_fr_pool(struct srp_target_port *target) dev->max_pages_per_mr); } -static void srp_drain_done(struct ib_cq *cq, struct ib_wc *wc) -{ - struct srp_rdma_ch *ch = cq->cq_context; - - complete(&ch->done); -} - -static struct ib_cqe srp_drain_cqe = { - .done = srp_drain_done, -}; - /** * srp_destroy_qp() - destroy an RDMA queue pair * @ch: SRP RDMA channel. * - * Change a queue pair into the error state and wait until all receive - * completions have been processed before destroying it. This avoids that - * the receive completion handler can access the queue pair while it is + * Drain the qp before destroying it. This avoids that the receive + * completion handler can access the queue pair while it is * being destroyed. */ static void srp_destroy_qp(struct srp_rdma_ch *ch) { - static struct ib_qp_attr attr = { .qp_state = IB_QPS_ERR }; - static struct ib_recv_wr wr = { 0 }; - struct ib_recv_wr *bad_wr; - int ret; - - wr.wr_cqe = &srp_drain_cqe; - /* Destroying a QP and reusing ch->done is only safe if not connected */ - WARN_ON_ONCE(ch->connected); - - ret = ib_modify_qp(ch->qp, &attr, IB_QP_STATE); - WARN_ONCE(ret, "ib_cm_init_qp_attr() returned %d\n", ret); - if (ret) - goto out; - - init_completion(&ch->done); - ret = ib_post_recv(ch->qp, &wr, &bad_wr); - WARN_ONCE(ret, "ib_post_recv() returned %d\n", ret); - if (ret == 0) - wait_for_completion(&ch->done); - -out: + ib_drain_qp(ch->qp); ib_destroy_qp(ch->qp); } @@ -508,7 +476,7 @@ static int srp_create_ch_ib(struct srp_rdma_ch *ch) if (!init_attr) return -ENOMEM; - /* queue_size + 1 for ib_drain_qp */ + /* queue_size + 1 for ib_drain_qp() */ recv_cq = ib_alloc_cq(dev->dev, ch, target->queue_size + 1, ch->comp_vector, IB_POLL_SOFTIRQ); if (IS_ERR(recv_cq)) { @@ -516,7 +484,8 @@ static int srp_create_ch_ib(struct srp_rdma_ch *ch) goto err; } - send_cq = ib_alloc_cq(dev->dev, ch, m * target->queue_size, + /* queue_size + 1 for ib_drain_qp() */ + send_cq = ib_alloc_cq(dev->dev, ch, m * target->queue_size + 1, ch->comp_vector, IB_POLL_DIRECT); if (IS_ERR(send_cq)) { ret = PTR_ERR(send_cq); @@ -524,7 +493,7 @@ static int srp_create_ch_ib(struct srp_rdma_ch *ch) } init_attr->event_handler = srp_qp_event; - init_attr->cap.max_send_wr = m * target->queue_size; + init_attr->cap.max_send_wr = m * target->queue_size + 1; init_attr->cap.max_recv_wr = target->queue_size + 1; init_attr->cap.max_recv_sge = 1; init_attr->cap.max_send_sge = 1; -- 2.7.0 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH 1/3] IB: new common API for draining a queue pair [not found] ` <cover.1454969695.git.swise-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org> 2016-01-14 18:24 ` [PATCH 2/3] iw_cxgb4: add drain_qp function Steve Wise 2016-01-27 20:09 ` [PATCH 3/3] IB/srp: use ib_drain_qp() Steve Wise @ 2016-02-05 21:13 ` Steve Wise 2016-02-09 20:04 ` [PATCH v2 0/3] new ib_drain_qp() API Steve Wise 3 siblings, 0 replies; 24+ messages in thread From: Steve Wise @ 2016-02-05 21:13 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA; +Cc: bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ From: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+p6NamaJ0bNTAL8bYrjMMd8@public.gmane.org> Add provider-specific drain_qp function for providers needing special drain logic. Add static function __ib_drain_qp() which posts noop WRs to the RQ and SQ and blocks until their completions are processed. This ensures the applications completions have all been processed. Add API function ib_drain_qp() which calls the provider-specific drain if it exists or __ib_drain_qp(). Reviewed-by: Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org> --- drivers/infiniband/core/verbs.c | 77 +++++++++++++++++++++++++++++++++++++++++ include/rdma/ib_verbs.h | 2 ++ 2 files changed, 79 insertions(+) diff --git a/drivers/infiniband/core/verbs.c b/drivers/infiniband/core/verbs.c index 5af6d02..98ddcb4 100644 --- a/drivers/infiniband/core/verbs.c +++ b/drivers/infiniband/core/verbs.c @@ -1657,3 +1657,80 @@ next_page: return i; } EXPORT_SYMBOL(ib_sg_to_pages); + +struct ib_drain_cqe { + struct ib_cqe cqe; + struct completion done; +}; + +static void ib_drain_qp_done(struct ib_cq *cq, struct ib_wc *wc) +{ + struct ib_drain_cqe *cqe = container_of(wc->wr_cqe, struct ib_drain_cqe, + cqe); + + complete(&cqe->done); +} + +/* + * Post a WR and block until its completion is reaped for both the RQ and SQ. + */ +static void __ib_drain_qp(struct ib_qp *qp) +{ + struct ib_qp_attr attr = { .qp_state = IB_QPS_ERR }; + struct ib_drain_cqe rdrain, sdrain; + struct ib_recv_wr rwr = {}, *bad_rwr; + struct ib_send_wr swr = {}, *bad_swr; + int ret; + + rwr.wr_cqe = &rdrain.cqe; + rdrain.cqe.done = ib_drain_qp_done; + init_completion(&rdrain.done); + + swr.wr_cqe = &sdrain.cqe; + sdrain.cqe.done = ib_drain_qp_done; + init_completion(&sdrain.done); + + ret = ib_modify_qp(qp, &attr, IB_QP_STATE); + if (ret) { + WARN_ONCE(ret, "failed to drain QP: %d\n", ret); + return; + } + + ret = ib_post_recv(qp, &rwr, &bad_rwr); + if (ret) { + WARN_ONCE(ret, "failed to drain recv queue: %d\n", ret); + return; + } + + ret = ib_post_send(qp, &swr, &bad_swr); + if (ret) { + WARN_ONCE(ret, "failed to drain send queue: %d\n", ret); + goto err_drain_rq; + } + + wait_for_completion(&sdrain.done); +err_drain_rq: + wait_for_completion(&rdrain.done); +} + +/** + * ib_drain_qp() - Block until all CQEs have been consumed by the + * application. + * @qp: queue pair to drain + * + * If the device has a provider-specific drain function, then + * call that. Otherwise call the generic drain function + * __ib_drain_qp(). + * + * The consumer must ensure there is room* in the CQ, SQ, and RQ + * for a drain work request. Also the consumer must allocate the + * CQ using ib_alloc_cq() and thus not directly polling the CQ. + */ +void ib_drain_qp(struct ib_qp *qp) +{ + if (qp->device->drain_qp) + qp->device->drain_qp(qp); + else + __ib_drain_qp(qp); +} +EXPORT_SYMBOL(ib_drain_qp); diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h index 284b00c..d8533ab 100644 --- a/include/rdma/ib_verbs.h +++ b/include/rdma/ib_verbs.h @@ -1846,6 +1846,7 @@ struct ib_device { int (*check_mr_status)(struct ib_mr *mr, u32 check_mask, struct ib_mr_status *mr_status); void (*disassociate_ucontext)(struct ib_ucontext *ibcontext); + void (*drain_qp)(struct ib_qp *qp); struct ib_dma_mapping_ops *dma_ops; @@ -3094,4 +3095,5 @@ int ib_sg_to_pages(struct ib_mr *mr, int sg_nents, int (*set_page)(struct ib_mr *, u64)); +void ib_drain_qp(struct ib_qp *qp); #endif /* IB_VERBS_H */ -- 2.7.0 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 24+ messages in thread
* RE: [PATCH v2 0/3] new ib_drain_qp() API [not found] ` <cover.1454969695.git.swise-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org> ` (2 preceding siblings ...) 2016-02-05 21:13 ` [PATCH 1/3] IB: new common API for draining a queue pair Steve Wise @ 2016-02-09 20:04 ` Steve Wise 2016-02-09 20:50 ` Steve Wise 3 siblings, 1 reply; 24+ messages in thread From: Steve Wise @ 2016-02-09 20:04 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA; +Cc: bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ > > This series creates a new helper API for draining a queue pair. It is a > rework of an original patch created by Christoph Hellwig as part of the CQ > API rework and was dropped to be resubmitted by me with iw_cxgb4 support. I finally got SRP running to test this series and it isn't working. :( Anyway, there will be v3 posted once I fix it. Steve. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: [PATCH v2 0/3] new ib_drain_qp() API 2016-02-09 20:04 ` [PATCH v2 0/3] new ib_drain_qp() API Steve Wise @ 2016-02-09 20:50 ` Steve Wise 2016-02-09 21:03 ` Bart Van Assche 0 siblings, 1 reply; 24+ messages in thread From: Steve Wise @ 2016-02-09 20:50 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA Cc: bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ, Sagi Grimberg, 'Christoph Hellwig', Chuck Lever > > This series creates a new helper API for draining a queue pair. It is a > > rework of an original patch created by Christoph Hellwig as part of the CQ > > API rework and was dropped to be resubmitted by me with iw_cxgb4 support. > > I finally got SRP running to test this series and it isn't working. :( Anyway, there will be v3 posted once I fix it. > > Steve. The problem is SRP creates its SQ CQ with IB_POLL_DIRECT context, so the CQ is never armed for interrupts, and SRP polls the CQ directly. So the drain logic won't work. I propose ib_drain_qp() takes a new parameter that tells it which queues to drain. Then the SRP code will only drain the RQ (which is what it is doing prior to this series). Thoughts? -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 0/3] new ib_drain_qp() API 2016-02-09 20:50 ` Steve Wise @ 2016-02-09 21:03 ` Bart Van Assche [not found] ` <56BA540B.4040405-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org> [not found] ` <011901d1637d$b5286400$1f792c00$@opengridcomputing.com> 0 siblings, 2 replies; 24+ messages in thread From: Bart Van Assche @ 2016-02-09 21:03 UTC (permalink / raw) To: Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA Cc: bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ, Sagi Grimberg, 'Christoph Hellwig', Chuck Lever On 02/09/2016 12:50 PM, Steve Wise wrote: >>> This series creates a new helper API for draining a queue pair. It is a >>> rework of an original patch created by Christoph Hellwig as part of the CQ >>> API rework and was dropped to be resubmitted by me with iw_cxgb4 support. >> >> I finally got SRP running to test this series and it isn't working. :( Anyway, there will be v3 posted once I fix it. >> >> Steve. > > The problem is SRP creates its SQ CQ with IB_POLL_DIRECT context, so the CQ is never armed for interrupts, and SRP polls the CQ > directly. So the drain logic won't work. > > I propose ib_drain_qp() takes a new parameter that tells it which queues to drain. Then the SRP code will only drain the RQ (which > is what it is doing prior to this series). Hello Steve, How about creating three functions - one that drains the receive queue, one that drains the send queue and a third function that drains both ? The latter function then can call the two former functions. And since only one of these three functions will have a user in your patch series (the function that drains the RQ), how about only introducing only that function now and to wait with introducing the two other functions until these have a user ? Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <56BA540B.4040405-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>]
* RE: [PATCH v2 0/3] new ib_drain_qp() API [not found] ` <56BA540B.4040405-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org> @ 2016-02-09 21:06 ` Steve Wise 2016-02-09 21:18 ` Chuck Lever 1 sibling, 0 replies; 24+ messages in thread From: Steve Wise @ 2016-02-09 21:06 UTC (permalink / raw) To: 'Bart Van Assche', linux-rdma-u79uwXL29TY76Z2rM5mHXA Cc: 'Sagi Grimberg', 'Christoph Hellwig', 'Chuck Lever' > > The problem is SRP creates its SQ CQ with IB_POLL_DIRECT context, so the CQ is never armed for interrupts, and SRP polls the CQ > > directly. So the drain logic won't work. > > > > I propose ib_drain_qp() takes a new parameter that tells it which queues to drain. Then the SRP code will only drain the RQ (which > > is what it is doing prior to this series). > > Hello Steve, > > How about creating three functions - one that drains the receive queue, > one that drains the send queue and a third function that drains both ? > The latter function then can call the two former functions. And since > only one of these three functions will have a user in your patch series > (the function that drains the RQ), how about only introducing only that > function now and to wait with introducing the two other functions until > these have a user ? That sounds reasonable. Simpler too perhaps. We'll see if anyone else has an opinion. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 0/3] new ib_drain_qp() API [not found] ` <56BA540B.4040405-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org> 2016-02-09 21:06 ` Steve Wise @ 2016-02-09 21:18 ` Chuck Lever [not found] ` <08D51C34-0009-4784-BE80-7BCB85441606-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> 1 sibling, 1 reply; 24+ messages in thread From: Chuck Lever @ 2016-02-09 21:18 UTC (permalink / raw) To: Bart Van Assche Cc: Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Sagi Grimberg, Christoph Hellwig > On Feb 9, 2016, at 4:03 PM, Bart Van Assche <bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org> wrote: > > On 02/09/2016 12:50 PM, Steve Wise wrote: >>>> This series creates a new helper API for draining a queue pair. It is a >>>> rework of an original patch created by Christoph Hellwig as part of the CQ >>>> API rework and was dropped to be resubmitted by me with iw_cxgb4 support. >>> >>> I finally got SRP running to test this series and it isn't working. :( Anyway, there will be v3 posted once I fix it. >>> >>> Steve. >> >> The problem is SRP creates its SQ CQ with IB_POLL_DIRECT context, so the CQ is never armed for interrupts, and SRP polls the CQ >> directly. So the drain logic won't work. >> >> I propose ib_drain_qp() takes a new parameter that tells it which queues to drain. Then the SRP code will only drain the RQ (which >> is what it is doing prior to this series). > > Hello Steve, > > How about creating three functions - one that drains the receive queue, one that drains the send queue and a third function that drains both ? The latter function then can call the two former functions. And since only one of these three functions will have a user in your patch series (the function that drains the RQ), how about only introducing only that function now and to wait with introducing the two other functions until these have a user ? I would like xprtrdma to use the function that drains both. Is that one of the functions that is being left out? -- Chuck Lever -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <08D51C34-0009-4784-BE80-7BCB85441606-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>]
* RE: [PATCH v2 0/3] new ib_drain_qp() API [not found] ` <08D51C34-0009-4784-BE80-7BCB85441606-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> @ 2016-02-09 21:20 ` Steve Wise 2016-02-09 21:35 ` Chuck Lever 0 siblings, 1 reply; 24+ messages in thread From: Steve Wise @ 2016-02-09 21:20 UTC (permalink / raw) To: 'Chuck Lever', 'Bart Van Assche' Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Sagi Grimberg', 'Christoph Hellwig' > > Hello Steve, > > > > How about creating three functions - one that drains the receive queue, one that drains the send queue and a third function that drains > both ? The latter function then can call the two former functions. And since only one of these three functions will have a user in your patch > series (the function that drains the RQ), how about only introducing only that function now and to wait with introducing the two other > functions until these have a user ? > > I would like xprtrdma to use the function that drains both. > Is that one of the functions that is being left out? > That is Bart's proposal. Perhaps we could add an xprtrdma patch to the series? Then we'll have a user for flushing both. Is the change trivial? -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 0/3] new ib_drain_qp() API 2016-02-09 21:20 ` Steve Wise @ 2016-02-09 21:35 ` Chuck Lever 0 siblings, 0 replies; 24+ messages in thread From: Chuck Lever @ 2016-02-09 21:35 UTC (permalink / raw) To: Steve Wise Cc: Bart Van Assche, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Sagi Grimberg, Christoph Hellwig > On Feb 9, 2016, at 4:20 PM, Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org> wrote: > >>> Hello Steve, >>> >>> How about creating three functions - one that drains the receive queue, one that drains the send queue and a third function that > drains >> both ? The latter function then can call the two former functions. And since only one of these three functions will have a user in > your patch >> series (the function that drains the RQ), how about only introducing only that function now and to wait with introducing the two > other >> functions until these have a user ? >> >> I would like xprtrdma to use the function that drains both. >> Is that one of the functions that is being left out? >> > > That is Bart's proposal. Perhaps we could add an xprtrdma patch to the series? Then we'll have a user for flushing both. Is the > change trivial? Basically it will replace rpcrdma_flush_cqs(), so trivial in a code change sense. But xprtrdma does not use the new CQ API yet. I have patches in test for 4.6 to do that conversion. -- Chuck Lever -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <011901d1637d$b5286400$1f792c00$@opengridcomputing.com>]
* RE: [PATCH v2 0/3] new ib_drain_qp() API [not found] ` <011901d1637d$b5286400$1f792c00$@opengridcomputing.com> @ 2016-02-09 21:58 ` Steve Wise 2016-02-09 22:23 ` Chuck Lever 2016-02-10 10:33 ` Sagi Grimberg 0 siblings, 2 replies; 24+ messages in thread From: Steve Wise @ 2016-02-09 21:58 UTC (permalink / raw) To: 'Bart Van Assche', linux-rdma-u79uwXL29TY76Z2rM5mHXA Cc: 'Sagi Grimberg', 'Christoph Hellwig', 'Chuck Lever' > > Hello Steve, > > > > How about creating three functions - one that drains the receive queue, > > one that drains the send queue and a third function that drains both ? > > The latter function then can call the two former functions. And since > > only one of these three functions will have a user in your patch series > > (the function that drains the RQ), how about only introducing only that > > function now and to wait with introducing the two other functions until > > these have a user ? > > That sounds reasonable. Simpler too perhaps. We'll see if anyone else > has an opinion. Another option is for ib_drain_qp() to just skip queues with IB_POLL_DIRECT CQ processing. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 0/3] new ib_drain_qp() API 2016-02-09 21:58 ` Steve Wise @ 2016-02-09 22:23 ` Chuck Lever 2016-02-10 10:33 ` Sagi Grimberg 1 sibling, 0 replies; 24+ messages in thread From: Chuck Lever @ 2016-02-09 22:23 UTC (permalink / raw) To: Steve Wise Cc: Bart Van Assche, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Sagi Grimberg, Christoph Hellwig > On Feb 9, 2016, at 4:58 PM, Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org> wrote: > > >>> Hello Steve, >>> >>> How about creating three functions - one that drains the receive queue, >>> one that drains the send queue and a third function that drains both ? >>> The latter function then can call the two former functions. And since >>> only one of these three functions will have a user in your patch series >>> (the function that drains the RQ), how about only introducing only that >>> function now and to wait with introducing the two other functions until >>> these have a user ? >> >> That sounds reasonable. Simpler too perhaps. We'll see if anyone else >> has an opinion. > > Another option is for ib_drain_qp() to just skip queues with IB_POLL_DIRECT CQ processing. Does ib_drain_qp() recognize when one CQ is new-style, and one is old school? How about QPs with a single CQ? Since there is a requirement that each CQ is allocated via ib_alloc_cq, it would be good to assert that is true in ib_drain_qp() before you prepare and post the blank WRs. Or if you prefer not to handle it automatically, you could add a flag parameter to ib_drain_qp (IB_DRAIN_RQ, IB_DRAIN_SQ, or IB_DRAIN_BOTH). -- Chuck Lever -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 0/3] new ib_drain_qp() API 2016-02-09 21:58 ` Steve Wise 2016-02-09 22:23 ` Chuck Lever @ 2016-02-10 10:33 ` Sagi Grimberg [not found] ` <56BB11F0.9090203-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> 1 sibling, 1 reply; 24+ messages in thread From: Sagi Grimberg @ 2016-02-10 10:33 UTC (permalink / raw) To: Steve Wise, 'Bart Van Assche', linux-rdma-u79uwXL29TY76Z2rM5mHXA Cc: 'Sagi Grimberg', 'Christoph Hellwig', 'Chuck Lever' >>> Hello Steve, >>> >>> How about creating three functions - one that drains the receive queue, >>> one that drains the send queue and a third function that drains both ? >>> The latter function then can call the two former functions. And since >>> only one of these three functions will have a user in your patch series >>> (the function that drains the RQ), how about only introducing only that >>> function now and to wait with introducing the two other functions until >>> these have a user ? >> >> That sounds reasonable. Simpler too perhaps. We'll see if anyone else >> has an opinion. > > Another option is for ib_drain_qp() to just skip queues with IB_POLL_DIRECT CQ processing. I'd rather not skip silently anything. ib_drain_qp() semantics is that it drains all the pending posts on the queue-pair (i.e. both send and receive queues). We can split to send and receive, but the fact that srp uses direct polling CQ is not sufficient for that, most if not all will benefit from both. I'd suggest to look at the CQ context and act accordingly, something like: if (cq->poll_ctx == IB_POLL_DIRECT) { while (!wait_for_completion_timeout(&sdrain.done, mescs_to_jiffies(100)) ib_process_cq_direct(cq, 1024) } else { wait_for_completion(&sdrain.done); } Thoughts? -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <56BB11F0.9090203-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>]
* Re: [PATCH v2 0/3] new ib_drain_qp() API [not found] ` <56BB11F0.9090203-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> @ 2016-02-10 14:08 ` Bart Van Assche [not found] ` <56BB4479.8090009-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org> 2016-02-10 15:27 ` Steve Wise 1 sibling, 1 reply; 24+ messages in thread From: Bart Van Assche @ 2016-02-10 14:08 UTC (permalink / raw) To: Sagi Grimberg, Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA Cc: 'Sagi Grimberg', 'Christoph Hellwig', 'Chuck Lever' On 02/10/16 02:33, Sagi Grimberg wrote: > >>>> Hello Steve, >>>> >>>> How about creating three functions - one that drains the receive queue, >>>> one that drains the send queue and a third function that drains both ? >>>> The latter function then can call the two former functions. And since >>>> only one of these three functions will have a user in your patch series >>>> (the function that drains the RQ), how about only introducing only that >>>> function now and to wait with introducing the two other functions until >>>> these have a user ? >>> >>> That sounds reasonable. Simpler too perhaps. We'll see if anyone else >>> has an opinion. >> >> Another option is for ib_drain_qp() to just skip queues with IB_POLL_DIRECT CQ processing. > > I'd rather not skip silently anything. ib_drain_qp() semantics is that > it drains all the pending posts on the queue-pair (i.e. both send and > receive queues). > > We can split to send and receive, but the fact that srp uses direct > polling CQ is not sufficient for that, most if not all will benefit from > both. > > I'd suggest to look at the CQ context and act accordingly, something > like: > > if (cq->poll_ctx == IB_POLL_DIRECT) { > while (!wait_for_completion_timeout(&sdrain.done, > mescs_to_jiffies(100)) > ib_process_cq_direct(cq, 1024) > } else { > wait_for_completion(&sdrain.done); > } > > Thoughts? Hello Sagi, The above code will only work as expected if the caller won't call ib_process_cq_direct() for the same queue from another context. This needs to be documented clearly and all drivers in which a call to that code is introduced have to be verified to see whether that assumption holds. Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <56BB4479.8090009-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>]
* Re: [PATCH v2 0/3] new ib_drain_qp() API [not found] ` <56BB4479.8090009-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org> @ 2016-02-11 10:46 ` Sagi Grimberg [not found] ` <56BC6686.8030301-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> 0 siblings, 1 reply; 24+ messages in thread From: Sagi Grimberg @ 2016-02-11 10:46 UTC (permalink / raw) To: Bart Van Assche, Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA Cc: 'Sagi Grimberg', 'Christoph Hellwig', 'Chuck Lever' >> I'd suggest to look at the CQ context and act accordingly, something >> like: >> >> if (cq->poll_ctx == IB_POLL_DIRECT) { >> while (!wait_for_completion_timeout(&sdrain.done, >> mescs_to_jiffies(100)) >> ib_process_cq_direct(cq, 1024) >> } else { >> wait_for_completion(&sdrain.done); >> } >> >> Thoughts? > > Hello Sagi, > > The above code will only work as expected if the caller won't call > ib_process_cq_direct() for the same queue from another context. Why? ib_poll_cq is safe from multiple contexts. Is it because the completion structures are on stack? because if so we can easily move them to the cq... -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <56BC6686.8030301-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>]
* Re: [PATCH v2 0/3] new ib_drain_qp() API [not found] ` <56BC6686.8030301-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> @ 2016-02-11 15:15 ` Bart Van Assche [not found] ` <56BCA57A.4000500-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org> 0 siblings, 1 reply; 24+ messages in thread From: Bart Van Assche @ 2016-02-11 15:15 UTC (permalink / raw) To: Sagi Grimberg, Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA Cc: 'Sagi Grimberg', 'Christoph Hellwig', 'Chuck Lever' On 02/11/16 02:46, Sagi Grimberg wrote: >>> I'd suggest to look at the CQ context and act accordingly, something >>> like: >>> >>> if (cq->poll_ctx == IB_POLL_DIRECT) { >>> while (!wait_for_completion_timeout(&sdrain.done, >>> mescs_to_jiffies(100)) >>> ib_process_cq_direct(cq, 1024) >>> } else { >>> wait_for_completion(&sdrain.done); >>> } >>> >>> Thoughts? >> >> Hello Sagi, >> >> The above code will only work as expected if the caller won't call >> ib_process_cq_direct() for the same queue from another context. > > Why? ib_poll_cq is safe from multiple contexts. Is it because the > completion structures are on stack? because if so we can easily move > them to the cq... Hello Sagi, The srp_send_done() function accesses the ch->free_tx list without locking. This is safe because all existing ib_process_cq_direct(ch->send_cq, ...) calls occur while holding ch->lock. The approach suggested above breaks that assumption. Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <56BCA57A.4000500-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>]
* Re: [PATCH v2 0/3] new ib_drain_qp() API [not found] ` <56BCA57A.4000500-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org> @ 2016-02-11 16:11 ` Sagi Grimberg [not found] ` <56BCB2C3.9060408-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> 0 siblings, 1 reply; 24+ messages in thread From: Sagi Grimberg @ 2016-02-11 16:11 UTC (permalink / raw) To: Bart Van Assche, Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA Cc: 'Sagi Grimberg', 'Christoph Hellwig', 'Chuck Lever' > Hello Sagi, > > The srp_send_done() function accesses the ch->free_tx list without > locking. This is safe because all existing > ib_process_cq_direct(ch->send_cq, ...) calls occur while holding > ch->lock. The approach suggested above breaks that assumption. But srp_send_done won't get invoked for the ib_drain_qp post send because ->done doesn't point to it, Am I missing something? -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <56BCB2C3.9060408-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>]
* Re: [PATCH v2 0/3] new ib_drain_qp() API [not found] ` <56BCB2C3.9060408-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> @ 2016-02-11 18:54 ` Bart Van Assche 0 siblings, 0 replies; 24+ messages in thread From: Bart Van Assche @ 2016-02-11 18:54 UTC (permalink / raw) To: Sagi Grimberg, Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA Cc: 'Sagi Grimberg', 'Christoph Hellwig', 'Chuck Lever' On 02/11/2016 08:11 AM, Sagi Grimberg wrote: >> The srp_send_done() function accesses the ch->free_tx list without >> locking. This is safe because all existing >> ib_process_cq_direct(ch->send_cq, ...) calls occur while holding >> ch->lock. The approach suggested above breaks that assumption. > > But srp_send_done won't get invoked for the ib_drain_qp post send > because ->done doesn't point to it, Am I missing something? Hello Sagi, If it would be known that the send completion queue is empty then it wouldn't be needed to drain the send queue. And if it is not known whether or not the send queue is empty then for the SRP driver it is possible that calling ib_process_cq_direct() from inside the drain function will trigger a call to srp_send_done(). Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: [PATCH v2 0/3] new ib_drain_qp() API [not found] ` <56BB11F0.9090203-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> 2016-02-10 14:08 ` Bart Van Assche @ 2016-02-10 15:27 ` Steve Wise 2016-02-10 15:55 ` Steve Wise 2016-02-11 15:22 ` Doug Ledford 1 sibling, 2 replies; 24+ messages in thread From: Steve Wise @ 2016-02-10 15:27 UTC (permalink / raw) To: 'Sagi Grimberg', 'Bart Van Assche', linux-rdma-u79uwXL29TY76Z2rM5mHXA Cc: 'Sagi Grimberg', 'Christoph Hellwig', 'Chuck Lever' > >>> Hello Steve, > >>> > >>> How about creating three functions - one that drains the receive queue, > >>> one that drains the send queue and a third function that drains both ? > >>> The latter function then can call the two former functions. And since > >>> only one of these three functions will have a user in your patch series > >>> (the function that drains the RQ), how about only introducing only that > >>> function now and to wait with introducing the two other functions until > >>> these have a user ? > >> > >> That sounds reasonable. Simpler too perhaps. We'll see if anyone else > >> has an opinion. > > > > Another option is for ib_drain_qp() to just skip queues with IB_POLL_DIRECT CQ processing. > > I'd rather not skip silently anything. ib_drain_qp() semantics is that > it drains all the pending posts on the queue-pair (i.e. both send and > receive queues). > > We can split to send and receive, but the fact that srp uses direct > polling CQ is not sufficient for that, most if not all will benefit from > both. > If we split it into ib_drain_rq(), ib_drain_sq(), and ib_drain_qp(), then srp would only call ib_drain_rq(). Others can call ib_drain_qp() if they want both SQ and RQ drained. > I'd suggest to look at the CQ context and act accordingly, something > like: > > if (cq->poll_ctx == IB_POLL_DIRECT) { > while (!wait_for_completion_timeout(&sdrain.done, > mescs_to_jiffies(100)) > ib_process_cq_direct(cq, 1024) > } else { > wait_for_completion(&sdrain.done); > } > > Thoughts? I don't like the forced 100ms block. You could call ib_process_cq_direct() first and check the return code, then block if needed. But is there utility in providing drain for IB_POLL_DIRECT users? -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: [PATCH v2 0/3] new ib_drain_qp() API 2016-02-10 15:27 ` Steve Wise @ 2016-02-10 15:55 ` Steve Wise 2016-02-11 15:22 ` Doug Ledford 1 sibling, 0 replies; 24+ messages in thread From: Steve Wise @ 2016-02-10 15:55 UTC (permalink / raw) To: 'Sagi Grimberg', 'Bart Van Assche', linux-rdma-u79uwXL29TY76Z2rM5mHXA Cc: 'Sagi Grimberg', 'Christoph Hellwig', 'Chuck Lever' > > I'd suggest to look at the CQ context and act accordingly, something > > like: > > > > if (cq->poll_ctx == IB_POLL_DIRECT) { > > while (!wait_for_completion_timeout(&sdrain.done, > > mescs_to_jiffies(100)) > > ib_process_cq_direct(cq, 1024) > > } else { > > wait_for_completion(&sdrain.done); > > } > > > > Thoughts? > > I don't like the forced 100ms block. You could call ib_process_cq_direct() first and check the return code, then block if needed. My bad: there is no forced 100ms block. If the completion is ready, then it will not wait... -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 0/3] new ib_drain_qp() API 2016-02-10 15:27 ` Steve Wise 2016-02-10 15:55 ` Steve Wise @ 2016-02-11 15:22 ` Doug Ledford [not found] ` <56BCA741.6020800-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 1 sibling, 1 reply; 24+ messages in thread From: Doug Ledford @ 2016-02-11 15:22 UTC (permalink / raw) To: Steve Wise, 'Sagi Grimberg', 'Bart Van Assche', linux-rdma-u79uwXL29TY76Z2rM5mHXA Cc: 'Sagi Grimberg', 'Christoph Hellwig', 'Chuck Lever' [-- Attachment #1: Type: text/plain, Size: 1478 bytes --] On 02/10/2016 10:27 AM, Steve Wise wrote: >>>>> Hello Steve, >>>>> >>>>> How about creating three functions - one that drains the receive queue, >>>>> one that drains the send queue and a third function that drains both ? >>>>> The latter function then can call the two former functions. And since >>>>> only one of these three functions will have a user in your patch series >>>>> (the function that drains the RQ), how about only introducing only that >>>>> function now and to wait with introducing the two other functions until >>>>> these have a user ? >>>> >>>> That sounds reasonable. Simpler too perhaps. We'll see if anyone else >>>> has an opinion. >>> >>> Another option is for ib_drain_qp() to just skip queues with IB_POLL_DIRECT CQ processing. >> >> I'd rather not skip silently anything. ib_drain_qp() semantics is that >> it drains all the pending posts on the queue-pair (i.e. both send and >> receive queues). >> >> We can split to send and receive, but the fact that srp uses direct >> polling CQ is not sufficient for that, most if not all will benefit from >> both. >> > > If we split it into ib_drain_rq(), ib_drain_sq(), and ib_drain_qp(), then srp would only call ib_drain_rq(). Others can call > ib_drain_qp() if they want both SQ and RQ drained. I'm in favor of this kind of flexibility at the API level. -- Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> GPG KeyID: 0E572FDD [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 884 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <56BCA741.6020800-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v2 0/3] new ib_drain_qp() API [not found] ` <56BCA741.6020800-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> @ 2016-02-11 16:09 ` Sagi Grimberg [not found] ` <56BCB239.3020505-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> 0 siblings, 1 reply; 24+ messages in thread From: Sagi Grimberg @ 2016-02-11 16:09 UTC (permalink / raw) To: Doug Ledford, Steve Wise, 'Bart Van Assche', linux-rdma-u79uwXL29TY76Z2rM5mHXA Cc: 'Sagi Grimberg', 'Christoph Hellwig', 'Chuck Lever' >> >> If we split it into ib_drain_rq(), ib_drain_sq(), and ib_drain_qp(), then srp would only call ib_drain_rq(). Others can call >> ib_drain_qp() if they want both SQ and RQ drained. > > I'm in favor of this kind of flexibility at the API level. I'm fine with having three flavors... -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <56BCB239.3020505-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>]
* RE: [PATCH v2 0/3] new ib_drain_qp() API [not found] ` <56BCB239.3020505-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> @ 2016-02-11 16:10 ` Steve Wise 0 siblings, 0 replies; 24+ messages in thread From: Steve Wise @ 2016-02-11 16:10 UTC (permalink / raw) To: 'Sagi Grimberg', 'Doug Ledford', 'Bart Van Assche', linux-rdma-u79uwXL29TY76Z2rM5mHXA Cc: 'Sagi Grimberg', 'Christoph Hellwig', 'Chuck Lever' > >> > >> If we split it into ib_drain_rq(), ib_drain_sq(), and ib_drain_qp(), then srp would only call ib_drain_rq(). Others can call > >> ib_drain_qp() if they want both SQ and RQ drained. > > > > I'm in favor of this kind of flexibility at the API level. > > I'm fine with having three flavors... Me too. I'll respin. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2016-02-11 18:54 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-02-08 22:14 [PATCH v2 0/3] new ib_drain_qp() API Steve Wise [not found] ` <cover.1454969695.git.swise-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org> 2016-01-14 18:24 ` [PATCH 2/3] iw_cxgb4: add drain_qp function Steve Wise 2016-01-27 20:09 ` [PATCH 3/3] IB/srp: use ib_drain_qp() Steve Wise 2016-02-05 21:13 ` [PATCH 1/3] IB: new common API for draining a queue pair Steve Wise 2016-02-09 20:04 ` [PATCH v2 0/3] new ib_drain_qp() API Steve Wise 2016-02-09 20:50 ` Steve Wise 2016-02-09 21:03 ` Bart Van Assche [not found] ` <56BA540B.4040405-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org> 2016-02-09 21:06 ` Steve Wise 2016-02-09 21:18 ` Chuck Lever [not found] ` <08D51C34-0009-4784-BE80-7BCB85441606-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> 2016-02-09 21:20 ` Steve Wise 2016-02-09 21:35 ` Chuck Lever [not found] ` <011901d1637d$b5286400$1f792c00$@opengridcomputing.com> 2016-02-09 21:58 ` Steve Wise 2016-02-09 22:23 ` Chuck Lever 2016-02-10 10:33 ` Sagi Grimberg [not found] ` <56BB11F0.9090203-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> 2016-02-10 14:08 ` Bart Van Assche [not found] ` <56BB4479.8090009-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org> 2016-02-11 10:46 ` Sagi Grimberg [not found] ` <56BC6686.8030301-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> 2016-02-11 15:15 ` Bart Van Assche [not found] ` <56BCA57A.4000500-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org> 2016-02-11 16:11 ` Sagi Grimberg [not found] ` <56BCB2C3.9060408-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> 2016-02-11 18:54 ` Bart Van Assche 2016-02-10 15:27 ` Steve Wise 2016-02-10 15:55 ` Steve Wise 2016-02-11 15:22 ` Doug Ledford [not found] ` <56BCA741.6020800-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2016-02-11 16:09 ` Sagi Grimberg [not found] ` <56BCB239.3020505-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> 2016-02-11 16:10 ` Steve Wise
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.