--- On Fri, 1/18/13, Adrian Chadd <[email protected]> wrote:
> From: Adrian Chadd <[email protected]> > Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() > To: "Barney Cordoba" <[email protected]> > Cc: [email protected], "Luigi Rizzo" <[email protected]> > Date: Friday, January 18, 2013, 3:09 PM > On 18 January 2013 06:30, Barney > Cordoba <[email protected]> > 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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[email protected]"
