> The way I understand the sequence of events w/o the
> patch is:
>
> ib_req_notify_cq(IB_CQ_NEXT_COMP)
> CQE 1 added to queue
> callback scheduled via tasklet
> future callbacks disarmed
> callback function calls ib_req_notify_cq(IB_CQ_NEXT_COMP)
> callback function calls ib_po
> > Out of curiousity have you measured an improvement?
>
> It is a great improvement over a bunch of printks and then
> hitting BUG_ON() in __rds_ib_ring_used().
I think it would be better to understand that problem, since this patch
is not really fixing anything, just changing timing. So a
> I missed the fact the clear_bit is not atomic. So to make this
> complete I will send a new patch with protection on the clear bit.
> Would you like me to send a patch for user_mad too or would you push
> that?
Hmm, actually maybe clear_bit is atomic enough for us.
says:
* clear_bit() is
thanks, applied.
--
Roland Dreier || 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 majord...@vger.kernel.org
More majordomo info at htt
The way I understand the sequence of events w/o the
patch is:
ib_req_notify_cq(IB_CQ_NEXT_COMP)
CQE 1 added to queue
callback scheduled via tasklet
future callbacks disarmed
callback function calls ib_req_notify_cq(IB_CQ_NEXT_COMP)
callback function calls ib_poll_cq() and gets CQE
On Wed, Mar 31, 2010 at 8:57 PM, Roland Dreier wrote:
> > Processing the flag IB_CQ_REPORT_MISSED_EVENTS causes several IB
> > drivers to lock and unlock a spinlock. Full-speed SRP I/O can cause
> > this operation to be invoked more than 100.000 times a second, so the
> > flag IB_CQ_REPORT_MIS
> Processing the flag IB_CQ_REPORT_MISSED_EVENTS causes several IB
> drivers to lock and unlock a spinlock. Full-speed SRP I/O can cause
> this operation to be invoked more than 100.000 times a second, so the
> flag IB_CQ_REPORT_MISSED_EVENTS will have a small but measurable
> impact on SRP I/
On Wed, Mar 31, 2010 at 8:18 PM, Roland Dreier wrote:
>
> > The SRP initiator works fine without this patch, and this patch slows
> > down the SRP initiator.
>
> I do agree that there are no missed callbacks without this patch, but I
> don't see how it would slow things down... it seems to me it
> The SRP initiator works fine without this patch, and this patch slows
> down the SRP initiator.
I do agree that there are no missed callbacks without this patch, but I
don't see how it would slow things down... it seems to me it would avoid
some CQ event callbacks, especially for HCAs where
IB
> 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
On Wed, Mar 31, 2010 at 7:57 PM, Ralph Campbell
wrote:
>
> 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 fla
Can this be structure as:
do {
> 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
>
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 ca
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 ca
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 ca
The following patches update ISER, SRP and core to use the
IB_CQ_REPORT_MISSED_EVENTS when calling ib_req_notify_cq()
similar to the patch I sent out for RDS.
Since the QLogic HCAs use a separate thread to generate the CQ callback,
it is important to make sure it isn't delayed more than necessary.
Hi Jim,
On 25/Mar/10 18:44, Jim Schutt wrote:
Hi Yevgey,
On Thu, 2010-03-25 at 09:56 -0600, Yevgeny Kliteynik wrote:
Hi Sasha,
Dumping SL2VL tables in ROUTING verbosity level when QoS is on.
This is needed for SL2VL tables analysis in general, and for
routing engines that are using IB VLs in
17 matches
Mail list logo
