From owner-freebsd-net@FreeBSD.ORG Fri Mar 27 11:11:56 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 04DDE106564A for ; Fri, 27 Mar 2009 11:11:56 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id BD22B8FC1C for ; Fri, 27 Mar 2009 11:11:55 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 4EF8373098; Fri, 27 Mar 2009 12:16:54 +0100 (CET) Date: Fri, 27 Mar 2009 12:16:54 +0100 From: Luigi Rizzo To: Andrew Brampton Message-ID: <20090327111654.GA95104@onelab2.iet.unipi.it> References: <20090327071742.GA87385@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list 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 11:11:56 -0000 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. > > 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. cheers luigi