From owner-freebsd-net@FreeBSD.ORG Fri Mar 27 07:28:09 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 75A53106566B for ; Fri, 27 Mar 2009 07:28:09 +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 3AA3A8FC1B for ; Fri, 27 Mar 2009 07:28:09 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 6A9CF73098; Fri, 27 Mar 2009 08:17:42 +0100 (CET) Date: Fri, 27 Mar 2009 08:17:42 +0100 From: Luigi Rizzo To: Andrew Brampton Message-ID: <20090327071742.GA87385@onelab2.iet.unipi.it> References: 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 07:28:09 -0000 On Fri, Mar 27, 2009 at 12:47:45AM +0000, Andrew Brampton wrote: > Hi, > Linux has a feature called NAPI, which amongst other things has this > Interrupt initiated polling mode. Whilst the network traffic is quiet > the network interfaces use interrupts, however as soon as the load > becomes higher polling kicks in and stays like that until the load > drops again. > > I know that FreeBSD can do interrupts or polling, but not together. I > think that that NAPI pretty neat as it provides the benefits of both > interrupts and polling, namely low CPU load (when the network is not > busy), and high performance. I was wondering if anyone has considered > this approach in FreeBSD? If not why not? Is there some reason why the > binary FreeBSD approach is better? Or is it just that no one has > dedicated the time and effort to implement this feature? 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. 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. I don't know what is the status of polling these days -- when i wrote it, the architecture was designed for UP kernels, and I don't know if/how it has been revised to deal efficiently with the SMP kernels we have now (in other words: one or multiple polling loops, interaction with interrupt threads, etc.) cheers luigi