--- On Thu, 1/17/13, Adrian Chadd <adr...@freebsd.org> wrote:
> From: Adrian Chadd <adr...@freebsd.org> > Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() > To: "Luigi Rizzo" <ri...@iet.unipi.it> > Cc: "Barney Cordoba" <barney_cord...@yahoo.com>, freebsd-net@freebsd.org > Date: Thursday, January 17, 2013, 2:04 PM > 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. i don't think that's the case. The mitigation is a minimum delay. If the delay is longer than the minimum, you'd get an interrupt as soon as you enable it, which is clearly better than scheduling a task. BC _______________________________________________ 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"