Re: [PATCH] r8169: Reduce looping in the interrupt handler.

Francois Romieu [off-list ref] writes:

Eric W. Biederman [off-list ref] :
[...]

quoted

It is a bit weird but it also means we aren't playing silly games
with status inside the loop.  So if we go through the loop we ack
everything in status.

I fear we have some longstanding problem anyway :

1. quiescent state
2. packets are received
3. rtl8169_interrupt schedules napi, clears IntrStatus and exits
4. packets are received and some non-napi event happens
5. rtl8169_interrupt wakes up, reads IntrStatus and goes on...
6. rtl8169_poll wakes up, processes Rx and Tx napi events and goes on...
7. tp->intr_mask still equals ~tp->napi_event : rtl8169_interrupt
   handler does not even try to schedule napi.
8. more packets are received
9. rtl8169_interrupt clears IntrStatus
a. rtl8169_poll reenables napi scheduling, updates IntrMask and exits
b. rtl8169_interrupt reads a perfectly clean IntrStatus and exits

That would not surprise me.

Right now I really don't have much more test bandwidth.  So I tried
for something simple that would address my problem without
fundamentally changing the already tested logic.  I am not seeing any
of the weird corner cases where we get confused.  The changes to fix
that problem is totally killing my ability to use the NIC, because it
loops way to much.

Perhaps we should unconditionally ack everything after changing the 
interrupt mask?  If that would prevent races it sounds like a simple fix.

Eric

[...]

Right now I really don't have much more test bandwidth.  So I tried
for something simple that would address my problem without
fundamentally changing the already tested logic.

Fair enough.

[...]

Perhaps we should unconditionally ack everything after changing the 
interrupt mask  ? If that would prevent races it sounds like a simple
fix.

I should be able to implement something right this evening, please hold on.

-- 
Ueimor