On 17 January 2013 09:44, Luigi Rizzo <ri...@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 _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
