Date: Fri, 18 Jan 2013 06:50:03 -0800 (PST) From: Barney Cordoba <barney_cordoba@yahoo.com> To: Adrian Chadd <adrian@freebsd.org>, Luigi Rizzo <rizzo@iet.unipi.it> Cc: freebsd-net@freebsd.org Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() Message-ID: <1358520603.55904.YahooMailClassic@web121606.mail.ne1.yahoo.com> In-Reply-To: <20130117174427.GA65218@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
> the problem i was actually seeing are slightly different, > namely: > - once the driver lags behind, it does not have a chance to > recover > =A0 even if there are CPU cycles available, because both > interrupt=20 > =A0 rate and packets per interrupt are capped. > - much worse, once the input stream stops, you have a huge > backlog that > =A0 is not drained. And if, say, you try to ping the > machine, > =A0 the incoming packet is behind another 3900 packets, > so the first > =A0 interrupt drains 100 (but not the ping request, so no > response), > =A0 you keep going for a while, eventually the external > world sees the > =A0 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=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. 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 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 b= etween livelock and dropping packets. It's not an arbitrary decision. BC
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1358520603.55904.YahooMailClassic>