From owner-freebsd-net@FreeBSD.ORG Tue Oct 6 16:25:12 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 5B92D106566B for ; Tue, 6 Oct 2009 16:25:12 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx71.mail.ru (mx71.mail.ru [94.100.176.85]) by mx1.freebsd.org (Postfix) with ESMTP id 1357F8FC1B for ; Tue, 6 Oct 2009 16:25:11 +0000 (UTC) Received: from [217.25.27.27] (port=23387 helo=[217.25.27.27]) by mx71.mail.ru with asmtp id 1MvCqc-000Ppr-00; Tue, 06 Oct 2009 20:25:10 +0400 Message-ID: <4ACB6F60.7090407@mail.ru> Date: Tue, 06 Oct 2009 21:25:04 +0500 From: rihad User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: Eugene Grosbein References: <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006100726.GA26426@svzserv.kemerovo.su> <4ACB42D2.2070909@mail.ru> <20091006142152.GA42350@svzserv.kemerovo.su> <4ACB6223.1000709@mail.ru> <20091006161240.GA49940@svzserv.kemerovo.su> In-Reply-To: <20091006161240.GA49940@svzserv.kemerovo.su> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: freebsd-net@freebsd.org, Luigi Rizzo , Julian Elischer Subject: Re: dummynet dropping too many packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 16:25:12 -0000 Eugene Grosbein wrote: > On Tue, Oct 06, 2009 at 08:28:35PM +0500, rihad wrote: > >> I don't think net.inet.ip.intr_queue_maxlen is relevant to this problem, >> as net.inet.ip.intr_queue_drops is normally zero or very close to it at >> all times. > > When net.isr.direct is 1, this queue is used very seldom. > Would you change it to 0, it will be used extensively. > Ah, ok, thanks. I'll try that tomorrow. But still... > Try setting net.isr.direct to 0 and make large net.inet.ip.intr_queue_maxlen. > This way, one of your cores may run bce's thread, enqueue incoming > packets and return to work immediately. The rest of processing may be > performed by another kernel thread, hopefully using another core. > Just to see if this changes anything. top -S should help here too. It isn't the incoming bce0 losing packets, but rather the outgoing bce1, which is almost idle interrupt-wise: 29 root 1 -68 - 0K 16K CPU1 1 223:39 55.86% irq256: bce0 31 root 1 -68 - 0K 16K WAIT 2 19:27 4.10% irq257: bce1