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

[Barney Cordoba]

--- On Thu, 1/17/13, Adrian Chadd <adrian at freebsd.org> wrote:

> From: Adrian Chadd <adrian at freebsd.org>
> Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx()
> To: "Luigi Rizzo" <rizzo at iet.unipi.it>
> Cc: "Barney Cordoba" <barney_cordoba at yahoo.com>, freebsd-net at freebsd.org
> Date: Thursday, January 17, 2013, 2:04 PM
> 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.

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