Date: Fri, 18 Jan 2013 07:46:04 -0800 (PST) From: Barney Cordoba <barney_cordoba@yahoo.com> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: freebsd-net@freebsd.org, Adrian Chadd <adrian@freebsd.org> Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() Message-ID: <1358523964.72178.YahooMailClassic@web121601.mail.ne1.yahoo.com> In-Reply-To: <20130118145944.GA68125@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
--- On Fri, 1/18/13, Luigi Rizzo <rizzo@iet.unipi.it> wrote: > From: Luigi Rizzo <rizzo@iet.unipi.it> > Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() > To: "Barney Cordoba" <barney_cordoba@yahoo.com> > Cc: "Adrian Chadd" <adrian@freebsd.org>, freebsd-net@freebsd.org > Date: Friday, January 18, 2013, 9:59 AM > On Fri, Jan 18, 2013 at 06:50:03AM > -0800, Barney Cordoba wrote: > >=20 > > > 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=20 > > > ? 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. > >=20 > > This is a silly example. As I said before, the 100 work > limit is=20 > > 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. > >=20 > > If you're using workload and task queues because you > don't know how to=20 > > tune moderation the process_limit, that's one > discussion. But if you can't > >=A0 process all of the packets in your RX queue in > the interrupt window than > >=A0 you either need to tune your machine better or > get a faster machine. > >=20 > > 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. >=20 > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1358523964.72178.YahooMailClassic>