From owner-freebsd-net@FreeBSD.ORG Fri Mar 27 13:31:25 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE811106564A for ; Fri, 27 Mar 2009 13:31:25 +0000 (UTC) (envelope-from _pppp@mail.ru) Received: from mx44.mail.ru (mx44.mail.ru [94.100.176.58]) by mx1.freebsd.org (Postfix) with ESMTP id 4082E8FC0A for ; Fri, 27 Mar 2009 13:31:24 +0000 (UTC) (envelope-from _pppp@mail.ru) Received: from f86.mail.ru (f86.mail.ru [194.67.57.186]) by mx44.mail.ru (mPOP.Fallback_MX) with ESMTP id 23B6B380020EB; Fri, 27 Mar 2009 15:46:03 +0300 (MSK) Received: from mail by f86.mail.ru with local id 1LnBRP-0004FN-00; Fri, 27 Mar 2009 15:45:43 +0300 Received: from [95.108.174.98] by win.mail.ru with HTTP; Fri, 27 Mar 2009 15:45:43 +0300 From: Dmitriy <_pppp@mail.ru> To: Luigi Rizzo Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [95.108.174.98] Date: Fri, 27 Mar 2009 15:45:43 +0300 References: <20090327111654.GA95104@onelab2.iet.unipi.it> In-Reply-To: <20090327111654.GA95104@onelab2.iet.unipi.it> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: X-Mras: Ok Cc: freebsd-net@freebsd.org, Andrew Brampton Subject: Re[2]: Interrupts + Polling mode (similar to Linux's NAPI) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dmitriy <_pppp@mail.ru> List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 13:31:26 -0000 -----Original Message----- From: Luigi Rizzo To: Andrew Brampton Date: Fri, 27 Mar 2009 12:16:54 +0100 Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) > On Fri, Mar 27, 2009 at 11:05:00AM +0000, Andrew Brampton wrote: > > 2009/3/27 Luigi Rizzo : > > > The load of polling is pretty low (within 1% or so) even with > > > polling. The advantage of having interrupts is faster response > > > to incoming traffic, not CPU load. > > > > oh, I was under the impression that polling spun in a tight loop, thus > > using 100% of the processor. After a quick test I see this is not the > > case. I assume it will get to 100% CPU load if I saturate my network. > > Well the motivation for the original polling code in FreeBSD was > to keep the CPU usage under strict control -- you could set the > max CPU fraction that you wanted to dedicate to packet handling, > and you were guaranteed not to exceed that fraction. Well, polling(4) usually reduces the CPU load. But this is not essential for modern CPUs, except some software-only NICs (namely, Realtek 8139). It provides an average of 0.5ms delay for a packet delivery which is not suitable for many usage patterns, though. > > > There is nothing difficult in having both active, except figuring > > > out a good logic for when to disable polling on an interface > > > that has been quiet for a while. > > > > Looking at Linux's logic, it appears to poll until there are no more > > packets, and thus re-enables interrupts. > > the complete definition should be "no more packets for X seconds". > Enabling and disabling interrupts is slightly expensive so you > don't want to do it too often. I'd rather say "no more than N packets for the recent T seconds". > > cheers > luigi > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >