> ib_req_notify_cq(IB_CQ_NEXT_COMP) is not guaranteed to generate
> a callback for the next completion entered since there is a race
> between arming the callback and another CQE being added to the queue.
> The IB_CQ_REPORT_MISSED_EVENTS flag was added to detect this
> race and allow the verbs consumer to call ib_poll_cq() and
> ib_req_notify_cq() again to avoid delays in processing the CQE.
I'm not sure I understand the race you're fixing here... the existing
code does the rearm before polling:
> + int ret;
>
> port_priv = container_of(work, struct ib_mad_port_private, work);
> - ib_req_notify_cq(port_priv->cq, IB_CQ_NEXT_COMP);
>
> +again:
> while (ib_poll_cq(port_priv->cq, 1, &wc) == 1) {
> if (wc.status == IB_WC_SUCCESS) {
> switch (wc.opcode) {
> @@ -2246,6 +2247,10 @@ static void ib_mad_completion_handler(struct
> work_struct *work)
> } else
> mad_error_handler(port_priv, &wc);
> }
> + ret = ib_req_notify_cq(port_priv->cq, IB_CQ_NEXT_COMP |
> + IB_CQ_REPORT_MISSED_EVENTS);
> + if (ret > 0)
> + goto again;
The only issue with the existing code is that it may trigger extra
events that will find the CQ empty when polling.
So this may be a valid optimization but I don't see it fixing any missed
events. Am I missing something?
Also for all these fixes, I think you only want to rearm the CQ once and
go back and poll if you get a missed events warning; the next time the
CQ is empty, then you know another event will happen.
- R.
--
Roland Dreier <[email protected]> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
