From owner-freebsd-net@FreeBSD.ORG Wed Oct 10 15:16:59 2007 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 4FA4A16A41B for ; Wed, 10 Oct 2007 15:16:59 +0000 (UTC) (envelope-from emaste@phaedrus.sandvine.ca) Received: from gw.sandvine.com (gw.sandvine.com [199.243.201.138]) by mx1.freebsd.org (Postfix) with ESMTP id DBECF13C457 for ; Wed, 10 Oct 2007 15:16:58 +0000 (UTC) (envelope-from emaste@phaedrus.sandvine.ca) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by gw.sandvine.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Oct 2007 10:54:54 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id 0AA741171B; Wed, 10 Oct 2007 10:54:54 -0400 (EDT) Date: Wed, 10 Oct 2007 10:54:53 -0400 From: Ed Maste To: Michael DeMan Message-ID: <20071010145453.GA54106@sandvine.com> References: <4703F9C3.2060601@net.utcluj.ro> <4532.192.168.2.137.1191451931.squirrel@www.codeangels.com> <470535D6.7020601@net.utcluj.ro> <0D18E826-52EA-4BEC-9404-1C98BFCDD418@staff.openaccess.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0D18E826-52EA-4BEC-9404-1C98BFCDD418@staff.openaccess.org> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 10 Oct 2007 14:54:54.0287 (UTC) FILETIME=[84777DF0:01C80B4D] Cc: freebsd-net@freebsd.org, Cristian KLEIN , lists@codeangels.com Subject: Re: FreeBSD as a gigabit router 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: Wed, 10 Oct 2007 15:16:59 -0000 On Thu, Oct 04, 2007 at 12:02:56PM -0700, Michael DeMan wrote: > Also, we've noticed at least on FBSD 6.x that there seem to be very > few advantages in using polling on network interfaces. We still run > it, so that we have responsive SSH/BGP/OSPF processes on the > machines, but my testing has shown that for sheer throughput, there > is basically no difference. I'd be curious if anybody knows the > scoop on this. The polling mechanism includes a feedback mechanism that attempts to keep a certain amount of CPU time available for userland. It works well at keeping the system usable under high load, but it doesn't perform so well if you want to dedicate most of the CPU time to polling in order to get near the maximum throughput. I have some prototype code that addresses this, and the the throughput with the new polling algorithm beat the non-polling kernel perf. by a small margin. This won't make it into RELENG_7, but I plan to bring it to HEAD at some point. -Ed