From owner-freebsd-net@FreeBSD.ORG Wed Nov 21 08:30:10 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 599ADD2F for ; Wed, 21 Nov 2012 08:30:10 +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 AD3348FC19 for ; Wed, 21 Nov 2012 08:30:09 +0000 (UTC) Received: (qmail 783 invoked from network); 21 Nov 2012 10:02:55 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Nov 2012 10:02:55 -0000 Message-ID: <50AC910C.4030004@freebsd.org> Date: Wed, 21 Nov 2012 09:30:04 +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: Adrian Chadd Subject: Re: FreeBSD boxes as a 'router'... References: <1353448328.76219.YahooMailClassic@web121602.mail.ne1.yahoo.com> <50AC08EC.8070107@mu.org> <832757660.33924.1353460119408@238ae4dab3b4454b88aea4d9f7c372c1.nuevasync.com> <250266404.35502.1353464214924@238ae4dab3b4454b88aea4d9f7c372c1.nuevasync.com> <50AC8393.3060001@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Barney Cordoba , Jim Thompson , Alfred Perlstein , khatfield@socllc.net, "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Nov 2012 08:30:10 -0000 On 21.11.2012 08:55, Adrian Chadd wrote: > Something that has popped up a few times, even recently, is breaking > out of an RX loop after you service a number of frames. That is what I basically described. > During stupidly high levels of RX, you may find the NIC happily > receiving frames faster than you can service the RX queue. If this > occurs, you could end up just plain being stuck there. That's the live-lock. > So what I've done in the past is to loop over a certain number of > frames, then schedule a taskqueue to service whatever's left over. Taskqueue's shouldn't be used anymore. We've got ithreads now. Contrary to popular belief (and due to poor documentation) an ithread does not run at interrupt level. Only the fast interrupt handler does that. The ithread is a normal kernel thread tied to an fast interrupt handler and trailing it whenever it said INTR_SCHEDULE_ITHREAD. > I've also had to do some proactive frame dropping at the driver layer > when under ridiculous levels of RX load, but that's a different story. That's the CoDel stuff I mentioned where it tries to drop frames in a fair manner. > I wonder how many drivers break out of an RX loop after a fixed amount of time.. Most. The problem seems to be that the taskqueue runs at high priority effectively starving out other threads/processes again. -- Andre