Hi Roland,
Yes, you're right. The loop below is a fallback to detect possibly missing
irq events
by checking the eq pointer, which can be changed by irq handler.
@Anton, for above reason we can not remove the lock/unlock within the loop.
Thanks,
Nam
Roland Dreier <rdre...@cisco.com> wrote on 30.11.2009 06:26:35:
> [image removed]
>
> Re: [PATCH] IB/ehca: Reduce number of spin_lock/spin_unlocks in
ehca_poll_eqs
>
> Roland Dreier
>
> to:
>
> Anton Blanchard
>
> 30.11.2009 06:26
>
> Cc:
>
> Hoang-Nam Nguyen, Christoph Raisch, Stefan Roscher, Alexander
> Schmidt, Joachim Fenkes, linux-rdma
>
>
> > +
> > spin_lock_irqsave(&eq->spinlock, flags);
> > +
> > q_ofs = eq->ipz_queue.current_q_offset;
> > - spin_unlock_irqrestore(&eq->spinlock, flags);
> > do {
> > - spin_lock_irqsave(&eq->spinlock, flags);
> > q_ofs2 = eq->ipz_queue.current_q_offset;
> > - spin_unlock_irqrestore(&eq->spinlock, flags);
> > max--;
> > } while (q_ofs == q_ofs2 && max > 0);
> > +
> > + spin_unlock_irqrestore(&eq->spinlock, flags);
> > +
>
> Does this loop have to drop the lock to give the EQ code a chance to
> update the queue pointer? If I understand this correctly, the EQ
> polling code is just trying to have a fallback if interrupts don't
> work...
>
> - R.
--
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
