Date: Sat, 19 Jan 2013 06:17:45 -0800 (PST) From: Barney Cordoba <barney_cordoba@yahoo.com> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-net@freebsd.org, Luigi Rizzo <rizzo@iet.unipi.it> Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() Message-ID: <1358605065.60481.YahooMailClassic@web121604.mail.ne1.yahoo.com> In-Reply-To: <CAJ-Vmo=Lxyxi5-QEKLpqwHX2DjGw%2B-mo4_7T=i5cZZs84faOYA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--- On Fri, 1/18/13, Adrian Chadd <adrian@freebsd.org> wrote: > From: Adrian Chadd <adrian@freebsd.org> > Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() > To: "Barney Cordoba" <barney_cordoba@yahoo.com> > Cc: freebsd-net@freebsd.org, "Luigi Rizzo" <rizzo@iet.unipi.it> > Date: Friday, January 18, 2013, 3:09 PM > On 18 January 2013 06:30, Barney > Cordoba <barney_cordoba@yahoo.com> > wrote: > > > I don't see the distinction between the rx thread > getting re-scheduled > > "immediately" vs introducing another thread. In fact > you increase missed > > interrupts by this method. The entire point of > interrupt moderation is > > to tune the intervals where a driver is processed. > > The problem with interrupt moderation combined with > enabling/disabling > interrupts is that if you get it even slightly wrong, > you won't run the packet processing thread(s) until the next > interrupt > occurs - even if something is in the queue. Which is the point of interrupt moderation. Your argument is that "I only want 6000 interrupts per second, but I'm willing to launch N tasks that have the exact same processing load where N <= 20". So you're willing to have 120000 interrupts/task_queues per second (its only possible to get about 2000pps in 1/6000th of a second on a gigabit link unless you're fielding runts). This all comes down, again, to tuning. Luigi's example would result in 39 tasks being queued to process his 3900 backup with a process limit of 100. This would bypass the "next interrupt" by a wide margin. Is the point of moderation to not have the network task take over your system? If you don't care, then why not just set moderation to 20Kpps? The "work" should be the amount of time you're willing to process packets within the interrupt moderation window. The settings go hand in hand. I'm not saying that the task_queue idea is wrong; however in Luigi's example it will cause substantially more overhead by launching too many tasks. Unless you're still running a 700Mhz P3 100 is way too low for a workload limit. It's just arbitrarily silly. BC
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1358605065.60481.YahooMailClassic>