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

Barney Cordoba barney_cordoba at yahoo.com
Fri Jan 18 15:48:01 UTC 2013



--- On Fri, 1/18/13, Luigi Rizzo <rizzo at iet.unipi.it> wrote:

> From: Luigi Rizzo <rizzo at iet.unipi.it>
> Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx()
> To: "Barney Cordoba" <barney_cordoba at yahoo.com>
> Cc: "Adrian Chadd" <adrian at freebsd.org>, freebsd-net at freebsd.org
> Date: Friday, January 18, 2013, 9:59 AM
> On Fri, Jan 18, 2013 at 06:50:03AM
> -0800, Barney Cordoba wrote:
> > 
> > > 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.
> > > - 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.
> > 
> > This is a silly example. As I said before, the 100 work
> limit is 
> > arbitrary and too low for a busy network. If you have a
> backlog of
> > 3900 packets with a workload of 100, then your system
> is so incompetently
> > tuned that it's not even worthy of discussion.
> > 
> > If you're using workload and task queues because you
> don't know how to 
> > tune moderation the process_limit, that's one
> discussion. But if you can't
> >  process all of the packets in your RX queue in
> the interrupt window than
> >  you either need to tune your machine better or
> get a faster machine.
> > 
> > When you tune the work limit you're making a decision
> about the trade off between livelock and dropping packets.
> It's not an arbitrary decision.
> 
> maybe i am too incompetent to participate to this
> discussion.
> what do i know about this stuff, after all!

Think about how much better you could do if you actually understood
how it all worked?

BC


More information about the freebsd-net mailing list