From owner-freebsd-current@FreeBSD.ORG Tue Nov 6 10:22:05 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7E44413 for ; Tue, 6 Nov 2012 10:22:05 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 257208FC14 for ; Tue, 6 Nov 2012 10:22:04 +0000 (UTC) Received: (qmail 10916 invoked from network); 6 Nov 2012 11:57:33 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 6 Nov 2012 11:57:33 -0000 Message-ID: <5098E526.6070101@freebsd.org> Date: Tue, 06 Nov 2012 11:23:34 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Luigi Rizzo Subject: polling's future [was: Re: Dynamic Ticks/HZ] References: <509758B8.1000409@rewt.org.uk> <50975F6F.6010907@rewt.org.uk> <5097898C.9080109@rewt.org.uk> <20121105163654.GA12870@onelab2.iet.unipi.it> <5097E880.8010001@rewt.org.uk> <20121105165748.GA13098@onelab2.iet.unipi.it> In-Reply-To: <20121105165748.GA13098@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano , Joe Holden , Ryan Stone , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 10:22:06 -0000 On 05.11.2012 17:57, Luigi Rizzo wrote: > On Mon, Nov 05, 2012 at 04:25:36PM +0000, Joe Holden wrote: >> Luigi Rizzo wrote: >>> On Mon, Nov 05, 2012 at 08:11:41AM -0500, Ryan Stone wrote: >>>> On Mon, Nov 5, 2012 at 4:40 AM, Joe Holden wrote: >>>> >>>>> doh, running kernel wasn't as GENERIC as I thought it was, looks like >>>>> device polling not only breaks dynamic ticks but also reduces rx ability >>>>> significantly, exactly 150,000 pps per 1000hz on igb versus 650,000 >>>>> without >>>>> >>>>> Is this a known issue? (and if device polling isn't as useful as it once >>>>> was, should it be removed?) >>>>> >>>> Device polling on modern multiqueue NICs isn't very useful because you're >>>> limited to a single thread for handling packets. I have a patch that >>>> fixes >>>> this that I've let fall by the wayside. >>> >>> the 150,000 is result of the combination of the default value of >>> sysctl kern.polling.burst_max and kern.polling.idle_poll=0 >>> (i think this is the default value for the latter). >>> >>> The 150 was sized for the peak pps on a 100Mbit/s interface, >>> back in 2001. You should at least be able to raise the number >>> and see what kind of throughput you can achieve. >>> >>> This said, modern nics also have interrupt moderation so you >>> don't really need polling. >>> >>> cheers >>> luigi >> Hi Luigi, >> >> This makes sense, am I likely to achieve better throughput (in the >> forwarding path at this point) with netisr rather than polling, >> especially as mentioned above the igb does indeed have multiple queues >> for rx? > > at 1Gbit/s you probably don't need multiqueue (I am actually surpised > you can only do 650kpps, but perhaps because you are using ipfw and > not just doing plain forwarding ?) Hi Luigi, do you agree on polling having outlived its usefulness in the light of interrupt moderating NIC's and SMP complications/disadvantages? And also that in its current state it is providing no benefit, if not negative, and that fixing it for the current world-order is major undertaking that's not really beneficial considering superior alternatives? That nobody is maintaining it and taking care of and fixing the frequent problem, performance and bug reports? Additionally it misleads people without deep network knowledge to compile it into their kernel under wrong assumptions and see a degradation of performance, if not other side effects? Under these considerations I propose to remove polling support from current and 10.0 in lieu of upcoming superior alternatives (netmap enabled features). It was a great feature in the past but is beyond retirement and should live a peaceful live in the attic. -- Andre