From owner-freebsd-current@FreeBSD.ORG Tue Nov 6 11:41:25 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 4651AD17 for ; Tue, 6 Nov 2012 11:41:25 +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 957188FC17 for ; Tue, 6 Nov 2012 11:41:24 +0000 (UTC) Received: (qmail 14348 invoked from network); 6 Nov 2012 13:16:52 -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 13:16:52 -0000 Message-ID: <5098F7BD.9060204@freebsd.org> Date: Tue, 06 Nov 2012 12:42:53 +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: Fabien Thomas Subject: Re: 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> <5098E526.6070101@freebsd.org> <04A8DD03-71B2-4EFA-864B-522F49BF1478@netasq.com> In-Reply-To: <04A8DD03-71B2-4EFA-864B-522F49BF1478@netasq.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano , Luigi Rizzo , 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 11:41:25 -0000 On 06.11.2012 12:02, Fabien Thomas wrote: >>> >> >> Hi Luigi, >> >> do you agree on polling having outlived its usefulness in the light >> of interrupt moderating NIC's and SMP complications/disadvantages? >> > If you have only one interface yes polling is not really necessary. > > If you have 10 interfaces the interrupt moderation threshold is hard to find > to not saturate the system. > Doing polling at 8000hz in that case is a lot better regarding global interrupt level. OK. Is the problem the interrupt load itself, or the taskqueues? > The problem is that in the current state polling does not work well and people remember > the good old time where polling was better. Indeed. > rstone@ and myself have made some improvement to polling. > > You can find a diff here for 8.3 with updated intel driver : > http://people.freebsd.org/~fabient/polling/patch-pollif_8.3_11052012 > > - support multiqueue for ixgbe, igb, em. > - compat API for old driver > - keep interrupt for link / status > - user core mapping / auto mapping > - deadline to keep cpu available > - integrated to netisr > - deferred packet injection with optional prefetching This is a number of interesting but sometimes only tangentially related features. Lets focus on the network cpu monopolization issue first. > Performance are on par with interrupt but you can keep a system alive more easily > by accounting all network processing for the deadline (with direct dispatch). Would you be willing to work a solution with me with a load aware taskqueue as I proposed in a recent email to Luigi? That way we don't need special cases or features or even a normal server under DDoS wouldn't go down. -- Andre