From owner-freebsd-net@FreeBSD.ORG Sat May 11 20:12:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E0421C17 for ; Sat, 11 May 2013 20:12:59 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id 78198781 for ; Sat, 11 May 2013 20:12:59 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id q57so4992801wes.37 for ; Sat, 11 May 2013 13:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=biq3JpBKDoTTK1sIYqWUguduBYuza9VzNphy80Icq88=; b=Sgt97VBCh3iHktHcpwcAuLJc86Lftr8wbm3U861X63D8chSJQz7FjXB805ariw1X70 9rSPZeEBJKUxNf7Uu6RIyvFTYQcgryww9ywiWM+0RF0FaRyLwUDPqfn2WfcI4b9jXV03 nPD558cCvhLkPlVsMc6uM31Im03RNKniSbpYe6f+63fviKKSzJEHwtlVeOJ+omZhswvl 0MvjFyL8t3TRIw7tzin7w1WbjyGnDFmAUhBqXzdyPKTDPXLbM295l8Wdx4hfFSreUO0J Dkx4cCxmk29d7AbUfkx4c2HjEXT4bor+octgs+DL9ta+2FE7jU51LjwpYcO06LJ+rIyR J5Og== X-Received: by 10.180.183.133 with SMTP id em5mr10293997wic.26.1368303178628; Sat, 11 May 2013 13:12:58 -0700 (PDT) Received: from [192.168.2.30] ([2.176.140.14]) by mx.google.com with ESMTPSA id i4sm5703957wix.10.2013.05.11.13.12.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 11 May 2013 13:12:57 -0700 (PDT) Message-ID: <518EA643.5010505@gmail.com> Date: Sun, 12 May 2013 00:42:51 +0430 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Barney Cordoba Subject: Re: High CPU interrupt load on intel I350T4 with igb on 8.3 References: <1368287797.70288.YahooMailClassic@web121603.mail.ne1.yahoo.com> In-Reply-To: <1368287797.70288.YahooMailClassic@web121603.mail.ne1.yahoo.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, =?ISO-8859-1?Q?=22Cl=E9ment_Hermann_=28nodens=29=22?= , Eugene Grosbein 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: Sat, 11 May 2013 20:12:59 -0000 On 5/11/2013 8:26 PM, Barney Cordoba wrote: > Clearly you don't understand the problem. Your logic is that because other drivers are defective also; therefore its not a driver problem? The problem is caused by a multi-threaded driver that > haphazardly launches tasks and that doesn't manage the case that the rest of the system can't handle the load. It's no different than a driver that barfs when mbuf clusters are exhausted. The answer > isn't to increase memory or mbufs, even though that may alleviate the problem. The answer is to fix the driver, so that it doesn't crash the system for an event that is wholly predictable. igb has > 1) too many locks and 2) exasperates the problem by binding to cpus, which causes it to not only have to wait for the lock to free, but also for a specific cpu to become free. So it chugs along > happily until it encounters a bottleneck, at which point it quickly blows up the entire system in a domino effect. It needs to manage locks more efficiently, and also to detect when the backup is > unmanageable. Ever since FreeBSD 5 the answer has been "it's fixed in 7, or its fixed in 9, or it's fixed in 10". There will always be bottlenecks, and no driver should blow up the system no matter > what intermediate code may present a problem. Its the driver's responsibility to behave and to drop packets if necessary. BC And how the driver should behave? You suggest dropping the packets. Even if we accept that dropping packets is a good strategy in all configurations (which I doubt), the driver is definitely not the best place to implement it, since that involves duplication of similar code between drivers. Somewhere like the Ethernet layer is a much better choice to watch load of packets and drop them to prevent them to eat all the cores. Furthermore, ignoring the fact that pf is not optimized for multi-processors and blaming drivers for not adjusting themselves with the this pf's fault, is a bit unfair, I believe. -- Best regards. Hooman Fazaeli