two problems in dev/e1000/if_lem.c::lem_handle_rxtx()

[Adrian Chadd]

On 17 January 2013 09:44, Luigi Rizzo <rizzo at iet.unipi.it> wrote:

> (in the "lem" driver this cannot happen until you release some
> rx slots, which only happens once at the end of the lem_rxeof() routine,
> not long before re-enabling interrupts)

Right.

>> * .. and the hardware immediately sends you the MSI or signals an interrupt;
>> * .. thus you re-enter the RX processing thread almost(!) immediately.
>
> the problem i was actually seeing are slightly different, namely:
> - once the driver lags behind, it does not have a chance to recover
>   even if there are CPU cycles available, because both interrupt
>   rate and packets per interrupt are capped.

Right, but the interrupt isn't being continuously asserted whilst
there are packets there.
You just get a single interrupt when the queue has frames in it, and
you won't get a further interrupt for whatever the mitigation period
is (or ever, if you fill up the RX FIFO, right?)

> - much worse, once the input stream stops, you have a huge backlog that
>   is not drained. And if, say, you try to ping the machine,
>   the incoming packet is behind another 3900 packets, so the first
>   interrupt drains 100 (but not the ping request, so no response),
>   you keep going for a while, eventually the external world sees the
>   machine as not responding and stops even trying to talk to it.

Right, so you do need to do what you're doing - but I still think
there's a possibility of a race there.
Namely that your queue servicing does reach the end of the list (and
so you don't immediately reschedule the taskqueue) but some more
frames have arrived.
You have to wait for the next mitigated interrupt for that.




Adrian