[openib-general] Re: Disabling IRQ #201 message

[Michael S. Tsirkin]

Quoting r. Roland Dreier <roland at topspin.com>:
> Subject: Re: [openib-general] Re: Disabling IRQ #201 message
> 
>     Grant> If the IRQ line is asserted and we get another interrupt
>     Grant> for something we've already handled, then it means the
>     Grant> regular interrupt code really hasn't cleaned up
>     Grant> sufficiently.
>     Grant> There has to be some way to tell the card
>     Grant> what work has been done *OR* flush all inflight DMA (MMIO
>     Grant> read - Ouch!).  The interrupt handler needs to guarantee it
>     Grant> has handled pending work and communicatied that back to the
>     Grant> card so IRQ line is not asserted.
> 
> Due to the way interrupts are handled in the Mellanox HCA, I think it
> will be quite inefficient to guarantee that the interrupt line is not
> asserted when the interrupt handler exits, because:
> 
>  A. the HCA has multiple "event queues" (interrupt sources)
>  B. clearing interrupts is done by writing to a register (no
>     "clear-on-read" when reading the interrupt cause register)
> 
> So closing the race between clearing the interrupts and reading the
> interrupt cause register is very expensive -- we would end up doing
> twice as many MMIO reads as necessary in the common case.

I dont see how our HCA is different here.
Whatever way you choose to clear the interrupt, any device
may re-assert it before you get out of the handler.


> However it should be harmless to handle a "spurious" interrupt
> occasionally.  The kernel should only complain if 99900 out of the
> last 100000 interrupts are spurious, which we shouldn't see.

We may get up to 2 spurious interrupts per one regular one (
one per EQ).
So that is probably some other hardware problem.

>  - R.
> 

-- 
MST - Michael S. Tsirkin