From owner-freebsd-net@FreeBSD.ORG Tue Apr 28 14:26:42 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 378021065672 for ; Tue, 28 Apr 2009 14:26:42 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63901.mail.re1.yahoo.com (web63901.mail.re1.yahoo.com [69.147.97.116]) by mx1.freebsd.org (Postfix) with SMTP id E42618FC19 for ; Tue, 28 Apr 2009 14:26:41 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 74719 invoked by uid 60001); 28 Apr 2009 14:26:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240928801; bh=dHIdjw0HhEpSXkucAmxqcr2IzQroe2EokFC6M+AryaA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=sRJO8z6+uTGLG/XaR11yIDfoAf6CfP02tSL/xgD01Vd7y8haG4oNQ203OI9MpcWDWL29JHCd5vTRAprkFpmAF4fng5pSFI4pw5425IZ/80m9lBVjTRQN79jiHPaWMhsS/U4OmvTKQhpN7Q4oUTlGk2G/34CLwlbTE/cUdY6HOR8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mYovNidGtTjZ8gB4o52kb/tqgSnddy0HI5KE6b/74BAuEWDdTj9zUBXxypQpBW6KWl4RJiNCVaMBGgyhPQdb/PRO6xAp/XsLyGh5FER+lTCCfSaWAiNYz/pCeSZHSs8vocs6aKBfkBLQ7+S62/Jp/7dAP6qGXhUlq4B9ZFWjvOc=; Message-ID: <50451.74235.qm@web63901.mail.re1.yahoo.com> X-YMail-OSG: TAI4whMVM1lqiU2r8oaZ5YbrdsbuHV_6vy0HU2kFfpAM06YbNPj605ElyFhqXUeJFJz_KuhY96W_ZCc2q0yTUp30Ph3R.JpOROv1Ot8QGps_kqt8OmQGkSiz_TAR5YwHI1hEoXIvB6cQGKFHBJJmk5Lqv5cmmmHmkfPXccgqdv1Q6cI.gsbcXLlI93scyQM9xYwL_lo2tfOEKUzGuDLCdps_y7URp95oqENdmVma.Cmkwz7p8VkvInvp8ubaILaBUcFlkKPvy1PCGQbBTTgEx9rItbAhj1VmRZzzrXoKBganTwAZ_oG64CMyDIO_Ssmfnk48fjvsAvCI4A-- Received: from [98.242.223.106] by web63901.mail.re1.yahoo.com via HTTP; Tue, 28 Apr 2009 07:26:40 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Tue, 28 Apr 2009 07:26:40 -0700 (PDT) From: Barney Cordoba To: Paolo Pisati , fabient@freebsd.org In-Reply-To: <36906055-E1AE-486B-BA77-D260E0609BBB@netasq.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 14:26:42 -0000 --- On Tue, 4/28/09, Fabien Thomas wrote: > From: Fabien Thomas > Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) > To: "Paolo Pisati" > Cc: "FreeBSD Net" > Date: Tuesday, April 28, 2009, 5:49 AM > Le 28 avr. 09 =E0 11:04, Paolo Pisati a =E9crit : >=20 > > Fabien Thomas wrote: > >>=20 > >> To share my results: > >>=20 > >> I have done at work modification to the polling > code to do SMP polling (previously posted to this ml). > >>=20 > >> SMP polling (dynamic group of interface binded to > CPU) does not significantly improve the throughput (lock > contention seems to be the cause here). > >> The main advantage of polling with modern > interface is not the PPS (which is nearly the same) but the > global efficiency of the system when using multiple > interfaces (which is the case for Firewall). > >> The best configuration we have found with FreeBSD > 6.3 is to do polling on one CPU and keep the other CPU free > for other processing. In this configuration the whole system > >> is more efficient than with interrupt where all > the CPU are busy processing interrupt thread. > > out of curiosity: did you try polling on 4.x? i know > it doesn't "support" SMP over there, but last > time i tried polling on 7.x (or was it 6.x? i don't > remember...) > > i found it didn't gave any benefit, while > switching the system to 4.x showed a huge improvement. > >=20 >=20 > yes rewriting the core polling code started at half because > the polling code on 6.x and up perform badly (in our env) > regarding performance. > today 4.x is unbeatable regarding network perf (6.2 -> > 7.0 at least, i need to do more test on 7_stable and 8). >=20 > the other half of the work was to explore the SMP scaling > of the polling code to gain what we loose with fine grained > SMP kernel. The problem with all of this "analysis" is that it assumes that SMP coding scales intuitively; when the opposite is actually true.=20 What you fail to address is the basic fact that moderated interrupts (ie holding off interrupts to a set number of ints/second) is exactly the same as polling, as on an active system you'll get exactly X interrupts per second at equal intervals. So all of this chatter about polling being more efficient is simply bunk. The truth is that polling requires additional overhead to the system while interrupts do not. So if polling did better for you, its simply because=20 either=20 1) The polling code in the driver is better or 2) You tuned polling better than you tuned interrupt moderation. Barney=0A=0A=0A