From owner-freebsd-net@FreeBSD.ORG Sun Jul 15 10:26:03 2012 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 D3F0C106566C for ; Sun, 15 Jul 2012 10:26:03 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9B3518FC16 for ; Sun, 15 Jul 2012 10:26:03 +0000 (UTC) Received: by obbun3 with SMTP id un3so9636079obb.13 for ; Sun, 15 Jul 2012 03:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XVRN2FoIEUKrrOB+56xCYlFD7abZPUQto5zANhMhK3Y=; b=nt8wHFVtfnRLaWC0OfEuozJssyZlUnPgAfRsmik+Hy7btqiDCjW42FMEJGKE8eqHMf LC7adYS0aK59QiEcscDC6izSrDnwWOaBvcvrSbh09pOkuc7LSr4Bz1m78SCWlj4r521H ZQeInNWeUvcXVCkGoMl6SQEQi1vU+aVekHA3McFCWbc/wJWFTzfcJPsS3RYkPAUm+exw PuZbo8xjR7vTbA9qUT8mNaDnEgSlshxMiyBIMI/53SU2ESaESFG5C5IwqAVO3OwmOnRH EUxB/V2LLrhj+Ct5EJ3T7LNrORvRHgQhaXLOLlpxiaHq0iYkdA5bNA2SPBpUjlhGG9Nu 46LA== MIME-Version: 1.0 Received: by 10.182.226.104 with SMTP id rr8mr6170695obc.41.1342347963023; Sun, 15 Jul 2012 03:26:03 -0700 (PDT) Received: by 10.182.35.135 with HTTP; Sun, 15 Jul 2012 03:26:02 -0700 (PDT) In-Reply-To: <500060DB.3090407@myri.com> References: <4FFF9E48.6000403@myri.com> <500060DB.3090407@myri.com> Date: Sun, 15 Jul 2012 18:26:02 +0800 Message-ID: From: Sepherosa Ziehau To: Reese Faucette Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: question in tcp_do_segment() 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: Sun, 15 Jul 2012 10:26:03 -0000 On Sat, Jul 14, 2012 at 1:54 AM, Reese Faucette wrote: > Hi, freebsd-net- > > I don't have a testcase for this at the moment, but there's a test > in tcp_do_segment that looks backwards to me... > > http://svnweb.freebsd.org/base/release/9.0.0/sys/netinet/tcp_input.c?view=markup > > line 2398 - > if (!tcp_timer_active(tp, TT_REXMT) || > th->th_ack != tp->snd_una) > tp->t_dupacks = 0; > > says "If we get a DUP ack and the retransmit timer is NOT > fired, then ignore it and reset DUP ACK count." > > Isn't that exactly backwards? I could see ignoring the DUP ACK if we > know the retransmit timer HAS fired, and we don't want to interfere with > its retransmission efforts. The way the code is written now, as far as > I can see, completely defeats retransmission based on DUP acks. I > accidentally ran across this by breaking the timer, so that the > retransmit timer never fires, and my streams get stuck, even with plenty of > DUP ACKs. > > Am I missing something, or should that "!" go ? !tcp_timer_active() means that the connection's retransmit timer is not _set_ yet (please note, it is _not_ "has fired"). As far as I understand this code, it in turn means that this connection doesn't have any segments that were sent but not yet ACKed. Best Regards, sephe -- Tomorrow Will Never Die From owner-freebsd-net@FreeBSD.ORG Sun Jul 15 15:22:48 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 4B56E106567A for ; Sun, 15 Jul 2012 15:22:48 +0000 (UTC) (envelope-from fernando.gont.netbook.win@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id CA7678FC17 for ; Sun, 15 Jul 2012 15:22:47 +0000 (UTC) Received: by eekc4 with SMTP id c4so1149334eek.13 for ; Sun, 15 Jul 2012 08:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=77ip0/k4J4tQH8yX8yc1i28IQoOzZIdRqsbEQ9nh7gU=; b=d22u5FocZ+oNnrUnALEfTOPrv0nTvODpwHt6BL4NKYnA21oJH1nc+NZsi/kkThDh9x Dyfoi1pRYF9C0bsyOdSTvv10fMTSxOApE/3ZYjza80L4UdgTF9f9So8ulfi9qM+Ndt15 2cKm4QwqTCCOhZRZoxuJyhddz9cNp/ZGzUSFYovM2bbkIL03QYGI8vmskmiefwJpmDSq U6WQKQC4bwo5YGfieILByg8nqwYlL2bZrPZG7/id43X39Ik5axJKRCdvEzO/4I8nQRgh +QUJh9OPv7xRw6F/UfwoC1XR5pombNcrdXe8T+EHJEEvnEolSAWAMx0eFUQRH0lx7YsL KAWw== Received: by 10.14.221.2 with SMTP id q2mr5292907eep.18.1342365761532; Sun, 15 Jul 2012 08:22:41 -0700 (PDT) Received: from [10.0.0.114] (201.230.137.78.rev.vodafone.pt. [78.137.230.201]) by mx.google.com with ESMTPS id v49sm11381156eep.4.2012.07.15.08.22.38 (version=SSLv3 cipher=OTHER); Sun, 15 Jul 2012 08:22:40 -0700 (PDT) Sender: Fernando Gont Message-ID: <5002E024.4090304@gont.com.ar> Date: Sun, 15 Jul 2012 16:22:12 +0100 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: FreeBSD Net X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: IPv6 toolkit v1.2 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: Sun, 15 Jul 2012 15:22:48 -0000 Folks, FYI, we've released "IPv6 toolkit v1.2": a set of IPv6 security assessment tools that were produced as part of a project I carried out on behalf of the UK CPNI. The tarball for version 1.2 of the tool is available at: http://www.si6networks.com/research/ipv6-toolkit-v1.2.tar.gz> Additionally, we have a git repository for the tool: This toolkit can be employed to perform local IPv6 scans, assess a number of security aspects of IPv6 implementations, such as predictability of Fragment ID values, etc. It can also be employed to play with IPv6 address resolution, SLAAC, etc. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From owner-freebsd-net@FreeBSD.ORG Sun Jul 15 15:39:09 2012 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 86A0A1065672 for ; Sun, 15 Jul 2012 15:39:09 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id DFF3E8FC0C for ; Sun, 15 Jul 2012 15:39:08 +0000 (UTC) Received: from alph.allbsd.org (p2214-ipbf2707funabasi.chiba.ocn.ne.jp [123.225.119.214]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id q6FFcqpP035386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jul 2012 00:39:02 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.allbsd.org (8.14.5/8.14.5) with ESMTP id q6FFcoDf001890; Mon, 16 Jul 2012 00:38:52 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 16 Jul 2012 00:38:43 +0900 (JST) Message-Id: <20120716.003843.1234204731212196536.hrs@allbsd.org> To: fernando@gont.com.ar From: Hiroki Sato In-Reply-To: <5002E024.4090304@gont.com.ar> References: <5002E024.4090304@gont.com.ar> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Jul_16_00_38_43_2012_088)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Mon, 16 Jul 2012 00:39:02 +0900 (JST) X-Spam-Status: No, score=-96.6 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT, QENCPTR1, RCVD_IN_RP_RNBL, SAMEHELOBY2HOP, USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org Subject: Re: IPv6 toolkit v1.2 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: Sun, 15 Jul 2012 15:39:09 -0000 ----Security_Multipart(Mon_Jul_16_00_38_43_2012_088)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Fernando Gont wrote in <5002E024.4090304@gont.com.ar>: fe> Folks, fe> fe> FYI, we've released "IPv6 toolkit v1.2": a set of IPv6 security fe> assessment tools that were produced as part of a project I carried out fe> on behalf of the UK CPNI. fe> fe> The tarball for version 1.2 of the tool is available at: fe> http://www.si6networks.com/research/ipv6-toolkit-v1.2.tar.gz> fe> fe> Additionally, we have a git repository for the tool: fe> fe> fe> This toolkit can be employed to perform local IPv6 scans, assess a fe> number of security aspects of IPv6 implementations, such as fe> predictability of Fragment ID values, etc. It can also be employed to fe> play with IPv6 address resolution, SLAAC, etc. FYI, I am working on creating a port of your toolkit and will commit it into the ports collection. -- Hiroki ----Security_Multipart(Mon_Jul_16_00_38_43_2012_088)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAlAC5AMACgkQTyzT2CeTzy1g1ACfV+Qw9CM3Dvoj2XGo2/LcVfJ9 WpIAn1cJidJrer1g9C8aA3ZgOP22vbd+ =4cTV -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Jul_16_00_38_43_2012_088)---- From owner-freebsd-net@FreeBSD.ORG Sun Jul 15 15:42:35 2012 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 C5F48106564A; Sun, 15 Jul 2012 15:42:35 +0000 (UTC) (envelope-from fernando.gont.netbook.win@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2B51C8FC0A; Sun, 15 Jul 2012 15:42:35 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so2166996wgb.31 for ; Sun, 15 Jul 2012 08:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=cJ6oHpjCGm2BdGMUnJvsOJ40x/MmTJCHaJ2sZONm3dY=; b=xrdmbCUghg2abAsmQQRTaXsMH/MVNmEjl9xtdKLY9E85lST7FNybbfI2QLyL6VC+Hs hGo2QYBc3QOyL0VWIVeIOv3jvTq3WvaCZGN5x6nj7Y1GKjxXUTrTC478UYhV95sF5oE2 tqU8imDhcXQEvwKbgK9TOUSRVQ8ZuLOq1Jlem7BFh3u4/w9JLTyV5DfQTLrVHXQ2VKeL EQgq/CuOrZ/oz3GqcyYm9kFbZmyui5lnILyL/+5r7xgmQrcJEn5Wh7CiFOGpXMbFW+FR qCS/H2hxN1NXtQSNACL82JLanxFrsR3Ta0sG6YHVibjyS3d1ILw9tBqb89YqWAFRzI22 6onw== Received: by 10.216.167.135 with SMTP id i7mr4170209wel.97.1342366954159; Sun, 15 Jul 2012 08:42:34 -0700 (PDT) Received: from [10.0.0.114] (201.230.137.78.rev.vodafone.pt. [78.137.230.201]) by mx.google.com with ESMTPS id fb20sm24145819wid.1.2012.07.15.08.42.31 (version=SSLv3 cipher=OTHER); Sun, 15 Jul 2012 08:42:33 -0700 (PDT) Sender: Fernando Gont Message-ID: <5002E4CA.1040801@gont.com.ar> Date: Sun, 15 Jul 2012 16:42:02 +0100 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Hiroki Sato References: <5002E024.4090304@gont.com.ar> <20120716.003843.1234204731212196536.hrs@allbsd.org> In-Reply-To: <20120716.003843.1234204731212196536.hrs@allbsd.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: IPv6 toolkit v1.2 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: Sun, 15 Jul 2012 15:42:35 -0000 On 07/15/2012 04:38 PM, Hiroki Sato wrote: > > FYI, I am working on creating a port of your toolkit and will > commit it into the ports collection. Great! -- Please make sure to use this version of the tool (v1.2), rather than the one that had been announced a couple of weeks ago, since it contains a number of fixes. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From owner-freebsd-net@FreeBSD.ORG Sun Jul 15 15:47:42 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 6BC0E106564A for ; Sun, 15 Jul 2012 15:47:42 +0000 (UTC) (envelope-from reese@myri.com) Received: from myri.com (rrcs-24-43-81-194.west.biz.rr.com [24.43.81.194]) by mx1.freebsd.org (Postfix) with ESMTP id 4B92F8FC0C for ; Sun, 15 Jul 2012 15:47:42 +0000 (UTC) Received: from ssl-tls.localdomain (ssl-tls.myri-local.com [172.31.0.162]) by myri.com (8.13.7+Sun/8.13.7) with ESMTP id q6FFlYr9007341; Sun, 15 Jul 2012 08:47:34 -0700 (PDT) Received: from [10.11.2.90] (unknown [12.153.182.2]) by ssl-tls.localdomain (Postfix) with ESMTP id 31982D0D6CD; Sun, 15 Jul 2012 08:47:34 -0700 (PDT) Message-ID: <5002E616.8050202@myri.com> Date: Sun, 15 Jul 2012 08:47:34 -0700 From: Reese Faucette User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Sepherosa Ziehau References: <4FFF9E48.6000403@myri.com> <500060DB.3090407@myri.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: question in tcp_do_segment() 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: Sun, 15 Jul 2012 15:47:42 -0000 On 7/15/2012 3:26 AM, Sepherosa Ziehau wrote: > !tcp_timer_active() means that the connection's retransmit timer is > not _set_ yet (please note, it is _not_ "has fired"). As far as I > understand this code, it in turn means that this connection doesn't > have any segments that were sent but not yet ACKed. You'd think that was the case from the name, but tcp_timer_active() calls callout_active() which checks for fired. If you want to check for "timer set" you need to use callout_pending(). -reese From owner-freebsd-net@FreeBSD.ORG Sun Jul 15 20:54:57 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 0AD9F106566C; Sun, 15 Jul 2012 20:54:57 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id B80F08FC12; Sun, 15 Jul 2012 20:54:56 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id q6FKsoMg092293; Sun, 15 Jul 2012 16:54:50 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <50032E10.3060607@sentex.net> Date: Sun, 15 Jul 2012 16:54:40 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Przemyslaw Frasunek References: <20110513162311.GK95084@glebius.int.ru> <4DD298AD.2060905@frasunek.com> <20110517184613.GN74366@glebius.int.ru> <4FDB1D71.6050908@freebsd.lublin.pl> <20120615203142.GW28613@glebius.int.ru> <4FDBAFD7.9020606@freebsd.lublin.pl> <4FDF2F81.6030307@sentex.net> <4FDF3097.6080701@freebsd.lublin.pl> <4FE0EE62.5070905@freebsd.lublin.pl> <4FF7F2C6.5070401@freebsd.lublin.pl> <20120709081225.GJ21957@glebius.int.ru> <4FFBB7A8.90201@rdtc.ru> <4FFBCA96.3000605@freebsd.lublin.pl> In-Reply-To: <4FFBCA96.3000605@freebsd.lublin.pl> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: freebsd-net@freebsd.org, Ryan Stone , Eugene Grosbein , bzeeb-lists@lists.zabbadoz.net Subject: Re: mpd5/Netgraph issues after upgrading to 7.4 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: Sun, 15 Jul 2012 20:54:57 -0000 On 7/10/2012 2:24 AM, Przemyslaw Frasunek wrote: >> It seems, Przemyslaw Frasunek uses proxyarp? >> I have no such problems but I do not use proxyarp. >> Could you get rid of it, Przemyslaw? > > No, I don't use proxy ARP. I have about 300 PPPoE ng interfaces and 10 VLANs > with plain IP traffic. ARP table has only < 50 entries, all of them are dynamic. I had a new one. Unfortunately, it did not generate a coredump file for some reason. Kernel was from ~ mid Feb Fatal trap 9: general protection fault while in kernel mode cpuid = 1; apic id = 02 instruction pointer = 0x20:0xffffffff80496e59 stack pointer = 0x28:0xffffff80000863b0 frame pointer = 0x28:0xffffff80000863c0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 13 (ng_queue1) trap number = 9 panic: general protection fault cpuid = 1 KDB: stack backtrace: #0 0xffffffff803f922e at kdb_backtrace+0x5e #1 0xffffffff803c6437 at panic+0x187 #2 0xffffffff80646e30 at trap_fatal+0x290 #3 0xffffffff8064736a at trap+0x10a #4 0xffffffff8062eb94 at calltrap+0x8 #5 0xffffffff8049835b at ng_l2tp_rcvdata_lower+0x42b #6 0xffffffff8048f380 at ng_apply_item+0x420 #7 0xffffffff80491790 at ng_snd_item+0x3f0 #8 0xffffffff804962ba at ng_ksocket_incoming2+0x24a #9 0xffffffff8048f50d at ng_apply_item+0x5ad #10 0xffffffff804912be at ngthread+0x22e #11 0xffffffff8039b08f at fork_exit+0x11f #12 0xffffffff8062f0de at fork_trampoline+0xe Uptime: 151d12h10m10s ipfw: 11 Deny TCP 192.168.1.99:33822 208.47.254.32:80 in via ng471 Dumping 883 out of 8145 MB:ipfw: 13 Deny UDP 64.7.157.21:512 192.168.254.46:137 in via ng21 panic: bufwrite: buffer is not busy??? cpuid = 1 Uptime: 151d12h10m10s -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Sun Jul 15 21:23:32 2012 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 D23E2106566C; Sun, 15 Jul 2012 21:23:32 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1AD3E8FC0A; Sun, 15 Jul 2012 21:23:31 +0000 (UTC) Received: by lbon10 with SMTP id n10so8330630lbo.13 for ; Sun, 15 Jul 2012 14:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=N7pb30PQ92c9QQqBYUW9SpzgRLJM1dD3YbBjCSoBqbo=; b=HhliD6Dsq8WVfAfy1sBzU+oW/WWG65rlHyzodKM+FXevvZlmkSErVgadFEZeZDeIvo ZZA+zKcGjO+f9+SRn46+3XiewZYdILfG/0lXVK/skkzF91RL5XD5eeCnXNtum63yPvsn rRwVTvpt8R0TD6KAsODQLzVw0MAjOwUqhDuOywwBfAYBIOH0/OK/e+d4QgdqaWa8rbBQ xmr2cYXeMIvWP3I7G38x4RiT8SUmHR9hAu2wlaIzNaBt0OMO/TXkmp2CQuDhZgxrDVpl xXVdqGCOmGn4IJ3iuKNWx2vYpLpQzVnbIhMPZVADtVtFZPrpiiRISzPqdog9QU5KjPnl xzZA== MIME-Version: 1.0 Received: by 10.112.102.136 with SMTP id fo8mr4378966lbb.106.1342387410889; Sun, 15 Jul 2012 14:23:30 -0700 (PDT) Received: by 10.112.66.135 with HTTP; Sun, 15 Jul 2012 14:23:30 -0700 (PDT) In-Reply-To: <4FCBFFC8.8000402@freebsd.org> References: <4FBF88CE.20209@cs.duke.edu> <4FC82D6C.4050309@freebsd.org> <4FCBFFC8.8000402@freebsd.org> Date: Sun, 15 Jul 2012 14:23:30 -0700 Message-ID: From: Kevin Oberman To: Lawrence Stewart Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Andrew Gallatin , Andrew Gallatin Subject: Re: Major performance hit with ToS setting 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: Sun, 15 Jul 2012 21:23:32 -0000 On Sun, Jun 3, 2012 at 5:22 PM, Lawrence Stewart wro= te: > On 06/03/12 15:18, Kevin Oberman wrote: >> >> On Fri, Jun 1, 2012 at 2:48 AM, Lawrence Stewart >> =C2=A0wrote: >>> >>> On 05/31/12 13:33, Kevin Oberman wrote: >>> [snip] >>>> >>>> >>>> I used SIFTR at the suggestion of Lawrence Stewart who headed the >>>> >>>> project to bring plugable congestion algorithms to FreeBSD and found >>>> really odd congestion behavior. First, I do see a triple ACK, but the >>>> congestion window suddenly drops from 73K to 8K. If I understand >>>> CUBIC, it should half the congestion window, not what is happening.. >>>> It then increases slowly (in slow start) to 82K. while the slow-start >>>> bytes are INCREASING, the congestion window again goes to 8K while the >>>> SS size moves from 36K up to 52K. It just continues to bound wildly >>>> between 8K (always the low point) and between 64k and 82K. The swings >>>> start at 83K and, over the first few seconds the peaks drop to about >>>> 64K. >>> >>> >>> >>> Oh, and a comment about this behaviour. Dropping back to 8k (1MSS) is >>> only >>> nasty if the TF_{CONG|FAST}RECOVERY flags are *not* set i.e. if you see >>> cwnd >>> grow, drop to 8k with those flags set, and then when the flags are unse= t, >>> cwnd starts at the value of ssthresh, then that is perfectly normal >>> recovery >>> behaviour. What *is* nasty is if an RTO fires, which will reset cwnd to >>> 8k, >>> ssthresh to 2*MSS and make the connection effectively start from scratc= h >>> again. >>> >>> There is evidence of RTOs in your siftr output, which is bad news e.g >>> here's >>> one example of 2 side-by-side log lines from your trace: >>> >>> # Direction,time,ssthresh,cwnd,flags >>> i,1338319593.574706,27044,27044,1630544864 >>> o,1338319593.831482,16384,8192,1092625377 >>> >>> Note the 300ms gap, and how cwnd resets to 1MSS and flags go from >>> 1630544864 >>> (TF_WASCRECOVERY|TF_CONGRECOVERY|TF_WASFRECOVERY|TF_FASTRECOVERY) to >>> 1092625377 (TF_WASCRECOVERY|TF_WASFRECOVERY). >> >> >> What can I say but that you are right. When I looked at the interface >> stats I found that the link overflow drops were through the roof! This >> confuses me a bit since the traffic is outbound and I woudl assume >> from the description on hte Myricom web page that these are input >> drops. A problem a problem with that card? =C2=A0On systems that are >> working "normally", I still see a sharp drop with the ToS bits set, >> but nothing nearly as drastic. Now it is a drop from 4.5G to 728M on a >> cross-country (US) circuit. >> >> I am now looking for issues on the route that might explain the >> performance, but the question of why the drop-of only shows up in >> FreeBSD 8 means something odd is still going on. It is even possible >> that the problem is with 7 and the losses are due to the policy for >> ToS 32 on the path. ToS 32 is less than best effort in our network. >> Maybe the marking was getting lost on 7. Not likely, but possible. > > > The receiver is FreeBSD 7? If so, have you tuned your reassembly queue on > that machine? If not, that could explain the RTOs you're seeing. Send > through the output of "sysctl net.inet.tcp.reass" and "netstat -sp tcp" > obtained from the receiver immediately before and after running a short > ToS=3D32 test. I just wanted to let those kind enough to help with this that I have analyzed the problem and pretty much understand what is happening. I've done a lot of testing fully understand what is going on. First, the problem is clearly tied to FreeBSD 8, but it is not anything wrong with FreeBSD. Instead it is a real fluke problem with the handing of the DSCP and TOS bits by a single Juniper router when TSO is used. V7 did not support TOS, so v7 does not show the problem. I have done packet capture on both ends and something really strange happens with the TSO. I see a couple of large segments move normally. Then things start getting weird. As soon as slow-start allows things to speed up just a bit, the second segment of a transfer is discarded and TCP tries to recover, but with the long pipe (RTT is around 50 ms. at 10G, there is a lot of data in the pipe when the problem is detected and the NAK is sent. Actually, 7 or 8 are sent before the transmitting system receives one and can start to recover. Then, it just happens again and again. the root problem is a router that seems to be re-marking the ToS bits from 0x20 to 0x24 which is adding the "loss priority" bit. Even though the circuit is not busy, TSO results in all segments being sent "back-to-back" and, with the change in the IP Precedence bits, the second packet gets dropped if ANY other traffic is present. We have a ticket open with the router vendor and I hope that we can get this resolved quickly, but I would not bet on it. In nay case, it is not a FreeBSD issue, though some what I see makes me suspect that our stack may not be responding well to this situation of massive loss in large segments. But the losses are so severe that I am far from certain and really can't expect anything but terrible results. Again, thinks to Lawrence, Bjorn, and Andrew for their and efforts to look at this and the the wireshark folks, without whom I would probably still be trying to understand what is going on. --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 00:13: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 4BA1C1065687; Mon, 16 Jul 2012 00:13:10 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id CD6BA8FC0C; Mon, 16 Jul 2012 00:13:09 +0000 (UTC) Received: from dhcp-128-232-132-140.eduroam.csx.cam.ac.uk (dhcp-128-232-132-140.eduroam.csx.cam.ac.uk [128.232.132.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPSA id 8DF3E25D3878; Mon, 16 Jul 2012 00:13:07 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <50032E10.3060607@sentex.net> Date: Mon, 16 Jul 2012 00:13:06 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <65702E3D-9373-4CC7-9CB4-81704EF44ED8@lists.zabbadoz.net> References: <20110513162311.GK95084@glebius.int.ru> <4DD298AD.2060905@frasunek.com> <20110517184613.GN74366@glebius.int.ru> <4FDB1D71.6050908@freebsd.lublin.pl> <20120615203142.GW28613@glebius.int.ru> <4FDBAFD7.9020606@freebsd.lublin.pl> <4FDF2F81.6030307@sentex.net> <4FDF3097.6080701@freebsd.lublin.pl> <4FE0EE62.5070905@freebsd.lublin.pl> <4FF7F2C6.5070401@freebsd.lublin.pl> <20120709081225.GJ21957@glebius.int.ru> <4FFBB7A8.90201@rdtc.ru> <4FFBCA96.3000605@freebsd.lublin.pl> <50032E10.3060607@sentex.net> To: Mike Tancsa X-Mailer: Apple Mail (2.1084) Cc: Przemyslaw Frasunek , Ryan Stone , Eugene Grosbein , freebsd-net@freebsd.org Subject: Re: mpd5/Netgraph issues after upgrading to 7.4 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: Mon, 16 Jul 2012 00:13:10 -0000 On 15. Jul 2012, at 20:54 , Mike Tancsa wrote: > On 7/10/2012 2:24 AM, Przemyslaw Frasunek wrote: >>> It seems, Przemyslaw Frasunek uses proxyarp? >>> I have no such problems but I do not use proxyarp. >>> Could you get rid of it, Przemyslaw? >>=20 >> No, I don't use proxy ARP. I have about 300 PPPoE ng interfaces and = 10 VLANs >> with plain IP traffic. ARP table has only < 50 entries, all of them = are dynamic. >=20 > I had a new one. Unfortunately, it did not generate a coredump file = for > some reason. Kernel was from ~ mid Feb >=20 > Fatal trap 9: general protection fault while in kernel mode > cpuid =3D 1; apic id =3D 02 ... > Uptime: 151d12h10m10s > ipfw: 11 Deny TCP 192.168.1.99:33822 208.47.254.32:80 in via ng471 > Dumping 883 out of 8145 MB:ipfw: 13 Deny UDP 64.7.157.21:512 > 192.168.254.46:137 in via ng21 > panic: bufwrite: buffer is not busy??? > cpuid =3D 1 > Uptime: 151d12h10m10s Hmm this one means we didn't stop all CPUs properly on panic; I think = that was fixed since? At least it's the reason you didn't have a chance to = get the core dump. However of course the initial problem leading to the panic of course is its own issue still. --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 01:53: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 350DC106566C for ; Mon, 16 Jul 2012 01:53:10 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id EEC6D8FC0C for ; Mon, 16 Jul 2012 01:53:09 +0000 (UTC) Received: by obbun3 with SMTP id un3so10882610obb.13 for ; Sun, 15 Jul 2012 18:53:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oElCVt/MWG/OAbCDe9dMfYymQ7xA9R0FdwsqxtySAVU=; b=ov5yGKaqBsVaUkqPJKtybcqb6/XzUfpO/RJp0MPEfeiMaNDhm28uwRs3lRbjthTU2m JhIOEf4MKeJsk43uPpCkuJ8e6nS6KwSTNtf34bt+WpHHn6jzkBbl6RmJmLiIcRYu1DdT St8BZgom9OttOYRQcyrEGab5o2F8ZRvoxmwr/BP0thVAs2EhPddX5WhhtwX7DCOoX2Aq G3CNjW470tXZywH/aWko5Ira4CcKjToYQiDN4mxrEMLlEd03ZPwoBuXQLKlz+jmLJg4e lgjoaUj/yI/kxOZ1GybxFth5A+ZxTteBiW3uj17k6GY8CPRiFP/CrmOTlTHi3OENevL6 qLAw== MIME-Version: 1.0 Received: by 10.60.168.230 with SMTP id zz6mr2183077oeb.11.1342403589591; Sun, 15 Jul 2012 18:53:09 -0700 (PDT) Received: by 10.182.35.135 with HTTP; Sun, 15 Jul 2012 18:53:09 -0700 (PDT) In-Reply-To: <5002E616.8050202@myri.com> References: <4FFF9E48.6000403@myri.com> <500060DB.3090407@myri.com> <5002E616.8050202@myri.com> Date: Mon, 16 Jul 2012 09:53:09 +0800 Message-ID: From: Sepherosa Ziehau To: Reese Faucette Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: question in tcp_do_segment() 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: Mon, 16 Jul 2012 01:53:10 -0000 On Sun, Jul 15, 2012 at 11:47 PM, Reese Faucette wrote: > On 7/15/2012 3:26 AM, Sepherosa Ziehau wrote: > >> !tcp_timer_active() means that the connection's retransmit timer is >> not _set_ yet (please note, it is _not_ "has fired"). As far as I >> understand this code, it in turn means that this connection doesn't >> have any segments that were sent but not yet ACKed. > > > You'd think that was the case from the name, but tcp_timer_active() calls > callout_active() which checks for fired. If you want to check for "timer Hmm, callout_active() is not used to check for whether the callout is fired or not; it is used to check whether callout_reset() has been called but callout_stop() is not yet been called. IMO, callout_reset() is "set" the callout, callout_stop() is "unset" the callout. AFAIR, callout_pending() is kinda check for whether the callback function of the callout "is being executed" or not (PENDING bit is probably cleared immediately before running the callback function). Best Regards, sephe > set" you need to use callout_pending(). > -reese > > -- Tomorrow Will Never Die From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 02:40:50 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D7651065670 for ; Mon, 16 Jul 2012 02:40:50 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id AF3B78FC24 for ; Mon, 16 Jul 2012 02:40:49 +0000 (UTC) Received: by obbun3 with SMTP id un3so10944273obb.13 for ; Sun, 15 Jul 2012 19:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=cu2MP/yEBWiYCCVOLauhp5gOEvvDPNUA606zP3Ua+I4=; b=eWPR71G8RzEALVyknaBpY8+Brg03Mlve0Z9Wrq5AbYDzYpo0VEPKSvC955D6+S1vXU DQSaI2QOCAnftmlz747ZKuSxv0kNDbcnqstEdGTSBWdtnRNEbXCCqXKv8g+3bqSDwnfq jrjzJWETP6QIoa/ij0fYY9qZHGYji+0XRgJ+Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=cu2MP/yEBWiYCCVOLauhp5gOEvvDPNUA606zP3Ua+I4=; b=GLxqCDiXGaHIgfgIzVHl2jqfYvwhbj+ZOFYJtIZvLCR0dVWGmBQtx7SNUj1I3Ah5gf yz6Kauv+kYoypKRiZ1on7Xo6gZss2/NPcqCZEMGYEaAcNwgk7ZCtC3lhdUNM0Bn2+kgy eKQlyNfS66ozLLn8UomSSrC/jlaf3U9cVyAtwwiyCcuUl6ddRphX6ldzAE7U/C37kiOz +IgSRN/a96kBl3hACduXhJfpkRzSziter8qwpOaHUTR+UuuN2K+uEVxosI9JRxoMhX64 sMwNROsqrvn4viPBn0+nUW56H3z0bi3Le8eldh0AevRQUcii7B1crEClgVjrsKx5E/hQ T2Yw== Received: by 10.50.161.199 with SMTP id xu7mr3312769igb.68.1342406449227; Sun, 15 Jul 2012 19:40:49 -0700 (PDT) Received: from DataIX.net ([99.181.132.147]) by mx.google.com with ESMTPS id if4sm7720041igc.10.2012.07.15.19.40.46 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 15 Jul 2012 19:40:48 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q6G2egRv090584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Jul 2012 22:40:42 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jh@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q6G2egpd090583; Sun, 15 Jul 2012 22:40:42 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Sun, 15 Jul 2012 22:40:42 -0400 From: Jason Hellenthal To: George Neville-Neil Message-ID: <20120716024042.GA90389@DataIX.net> References: <86liiqrnnq.wl%gnn@neville-neil.com> <4FFDF6C7.3030301@FreeBSD.org> <20120712165502.GA61341@DataIX.net> <096E1D9F-6F88-4063-B59C-34E94E17138D@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline In-Reply-To: <096E1D9F-6F88-4063-B59C-34E94E17138D@freebsd.org> X-Gm-Message-State: ALoCoQnuS5KltbaOC0J4Oqw4mb9Vo6AZkbcuDt01zxYKtYPKPnuJ4B5eiGCvBSKM8URIQeq9M476 Cc: Navdeep Parhar , net@freebsd.org Subject: Re: Interface MTU question... 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: Mon, 16 Jul 2012 02:40:50 -0000 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Filed as, http://www.freebsd.org/cgi/query-pr.cgi?pr=3D169898 Thanks for looking into this when you get time. On Thu, Jul 12, 2012 at 04:49:23PM -0400, George Neville-Neil wrote: >=20 > On Jul 12, 2012, at 12:55 , Jason Hellenthal wrote: >=20 > >=20 > >=20 > > On Thu, Jul 12, 2012 at 10:55:16AM -0400, George Neville-Neil wrote: > >>=20 > >> On Jul 11, 2012, at 17:57 , Navdeep Parhar wrote: > >>=20 > >>> On 07/11/12 14:30, gnn@freebsd.org wrote: > >>>> Howdy, > >>>>=20 > >>>> Does anyone know the reason for this particular check in > >>>> ip_output.c? > >>>>=20 > >>>> if (rte !=3D NULL && (rte->rt_flags & (RTF_UP|RTF_HOST))) { > >>>> /* > >>>> * This case can happen if the user changed the MTU > >>>> * of an interface after enabling IP on it. Because > >>>> * most netifs don't keep track of routes pointing to > >>>> * them, there is no way for one to update all its > >>>> * routes when the MTU is changed. > >>>> */ > >>>> if (rte->rt_rmx.rmx_mtu > ifp->if_mtu) > >>>> rte->rt_rmx.rmx_mtu =3D ifp->if_mtu; > >>>> mtu =3D rte->rt_rmx.rmx_mtu; > >>>> } else { > >>>> mtu =3D ifp->if_mtu; > >>>> } > >>>>=20 > >>>> To my mind the > ought to be !=3D so that any change, up or down, of= the > >>>> interface MTU is eventually reflected in the route. Also, this code > >>>> does not check if it is both a HOST route and UP, but only if it is > >>>> one other the other, so don't be fooled by that, this check happens > >>>> for any route we have if it's up. > >>>=20 > >>> I believe rmx_mtu could be low due to some intermediate node between = this host and the final destination. An increase in the MTU of the local i= nterface should not increase the path MTU if the limit was due to someone e= lse along the route. > >>=20 > >> Yes, it turns out to be complex. We have several places that store th= e MTU. There is the interface, > >> which knows the MTU of the directly connected link, a route, and the h= ost cache. All three of these > >> are used to determine the maximum segment size (MSS) of a TCP packet. = The route and the interface > >> determine the maximum MTU that the MSS can have, but, if there is an e= ntry in the host cache > >> then it is preferred over either of the first two. See tcp_update_mss= () in tcp_input.c to > >> see what I'm talking about. > >>=20 > >> I believe that the quoted code above has been wrong from the day it wa= s written, in that what it > >> really says is "if the route is up" and not "if the route is up and is= a host route" which is > >> what I believe people to read that as. If the belief is that this cod= e is really only there for > >> hosts routes, then the proper fix is to make the sense of the first if= match that belief > >> and, again, to change the > to !=3D so that when the administrator of = the box bumps the MTU in > >> either direction that the route reflects this. It is not possible for= PMTU on a single link > >> to a host route to bump the number down if the interface says it's not= to be bumped. And, > >> even so, any host cache entry will override and avoid this code. > >>=20 > >=20 > > Something else to look into ...=20 > >=20 > > # ifconfig lagg0 mtu 1492 > > ifconfig: ioctl (set mtu): Invalid argument > >=20 > > This is on stable/8 r238264 when the interface was up/up and down/down > >=20 > > Also attempted on the member interfaces dc0 and dc1 > >=20 >=20 > Can you file a bug on that one? >=20 > Best, > George >=20 --=20 - (2^(N-1)) --9amGYk9869ThD9tj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJQA38pAAoJEBSh2Dr1DU7WvJQH/35b7E7xtWAHmUB3HtalxeMc W4JLmWeIXey0uiBprk7dtRnqzFdUq6JVg/yU7XzL9k8HwNsnwuThpHEKI2ZbTpYq 1Jk8d8EcSlzF7QOU08JQuyy88rX0t81uBCgEd7XmdOo5cYmoqIOEMl5RMPY3+xRQ qJsO6zkDpDmrfDhBxX4DmzK5ixQ2ANzhz6PmrMgvrpuxSkCLz7dS/gfnnhwvEjad yOzva9XUPLoAz4VIJRyhHs4YS6lhPhdoI/igGguye6RiCVgl2CnA4hl6ISBcqX1p 6mRUeuUNzStaEKNd2RqOR6t64IGXDqXHP+QBvuJe4MlZSN17VtfjEXd6r3hep9Q= =XcGA -----END PGP SIGNATURE----- --9amGYk9869ThD9tj-- From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 02:55:21 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C4B2106566C; Mon, 16 Jul 2012 02:55:21 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4F4DD8FC08; Mon, 16 Jul 2012 02:55:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6G2tLNu013460; Mon, 16 Jul 2012 02:55:21 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6G2tLbf013456; Mon, 16 Jul 2012 02:55:21 GMT (envelope-from linimon) Date: Mon, 16 Jul 2012 02:55:21 GMT Message-Id: <201207160255.q6G2tLbf013456@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/169620: [ng] [pf] ng_l2tp incoming packet bypass pf firewall 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: Mon, 16 Jul 2012 02:55:21 -0000 Old Synopsis: ng_l2tp incomming packet bypass pf firewall New Synopsis: [ng] [pf] ng_l2tp incoming packet bypass pf firewall Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jul 16 02:54:51 UTC 2012 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=169620 From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 02:58:34 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE6B61065678; Mon, 16 Jul 2012 02:58:34 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 91E818FC21; Mon, 16 Jul 2012 02:58:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6G2wYGb013622; Mon, 16 Jul 2012 02:58:34 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6G2wYLx013618; Mon, 16 Jul 2012 02:58:34 GMT (envelope-from linimon) Date: Mon, 16 Jul 2012 02:58:34 GMT Message-Id: <201207160258.q6G2wYLx013618@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/169634: [bge] Network unavailable when booting directly to FreeBSD 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: Mon, 16 Jul 2012 02:58:34 -0000 Old Synopsis: bge: Network unavailable when booting directly to FreeBSD New Synopsis: [bge] Network unavailable when booting directly to FreeBSD Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jul 16 02:58:21 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=169634 From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 03:04:27 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E9481065672; Mon, 16 Jul 2012 03:04:27 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 72C738FC12; Mon, 16 Jul 2012 03:04:27 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6G34RVx014696; Mon, 16 Jul 2012 03:04:27 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6G34RjK014692; Mon, 16 Jul 2012 03:04:27 GMT (envelope-from linimon) Date: Mon, 16 Jul 2012 03:04:27 GMT Message-Id: <201207160304.q6G34RjK014692@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/169664: [bgp] Wrongful replacement of interface connected net route 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: Mon, 16 Jul 2012 03:04:27 -0000 Old Synopsis: Wrongful replacement of interface connected net route New Synopsis: [bgp] Wrongful replacement of interface connected net route Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jul 16 03:03:35 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=169664 From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 03:05:44 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E5A8106564A; Mon, 16 Jul 2012 03:05:44 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E538F8FC20; Mon, 16 Jul 2012 03:05:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6G35hFL014958; Mon, 16 Jul 2012 03:05:43 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6G35hd5014954; Mon, 16 Jul 2012 03:05:43 GMT (envelope-from linimon) Date: Mon, 16 Jul 2012 03:05:43 GMT Message-Id: <201207160305.q6G35hd5014954@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/169676: [bge] [hang] system hangs, fully or partially after receiving watchdog timeouts on bge 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: Mon, 16 Jul 2012 03:05:44 -0000 Old Synopsis: system hangs, fully or partially after receiving watchdog timeouts on bge New Synopsis: [bge] [hang] system hangs, fully or partially after receiving watchdog timeouts on bge Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jul 16 03:05:30 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=169676 From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 03:15:53 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4959A106566B; Mon, 16 Jul 2012 03:15:53 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1CDDF8FC1A; Mon, 16 Jul 2012 03:15:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6G3FqmF017457; Mon, 16 Jul 2012 03:15:52 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6G3FqhS017453; Mon, 16 Jul 2012 03:15:52 GMT (envelope-from linimon) Date: Mon, 16 Jul 2012 03:15:52 GMT Message-Id: <201207160315.q6G3FqhS017453@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/169826: [re] if_re no longer working in 9.x [regression] 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: Mon, 16 Jul 2012 03:15:53 -0000 Old Synopsis: if_re no longer working in 9.x New Synopsis: [re] if_re no longer working in 9.x [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jul 16 03:15:41 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=169826 From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 03:16:15 2012 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 908631065696 for ; Mon, 16 Jul 2012 03:16:15 +0000 (UTC) (envelope-from reese@myri.com) Received: from myri.com (rrcs-24-43-81-194.west.biz.rr.com [24.43.81.194]) by mx1.freebsd.org (Postfix) with ESMTP id 6E9D88FC17 for ; Mon, 16 Jul 2012 03:16:15 +0000 (UTC) Received: from ssl-tls.localdomain (ssl-tls.myri-local.com [172.31.0.162]) by myri.com (8.13.7+Sun/8.13.7) with ESMTP id q6G3GEQe025839; Sun, 15 Jul 2012 20:16:14 -0700 (PDT) Received: from [172.31.135.209] (reese-ovpn.sw.myri.com [172.31.135.209]) by ssl-tls.localdomain (Postfix) with ESMTP id 70FA6D0D6CD; Sun, 15 Jul 2012 20:16:14 -0700 (PDT) Message-ID: <5003877F.6070309@myri.com> Date: Sun, 15 Jul 2012 20:16:15 -0700 From: Reese Faucette User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Sepherosa Ziehau References: <4FFF9E48.6000403@myri.com> <500060DB.3090407@myri.com> <5002E616.8050202@myri.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: question in tcp_do_segment() 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: Mon, 16 Jul 2012 03:16:15 -0000 On 7/15/2012 6:53 PM, Sepherosa Ziehau wrote: >> On 7/15/2012 3:26 AM, Sepherosa Ziehau wrote: > Hmm, callout_active() is not used to check for whether the callout is > fired or not; it is used to check whether callout_reset() has been > called but callout_stop() is not yet been called. IMO, > callout_reset() is "set" the callout, callout_stop() is "unset" the > callout. OK, sorry, I was going by the callout implementation in 8.0 - I compared sources and the tcp_input code was roughly the same, tcp_timer_*() was roughly the same, but since all that was the same, I did not dig all the way to the bottom of callout_reset() implementation, and I see that the semantics of callout_active() have changed to be as you describe. My callout_active() from 8.0 is: #define callout_active(c) ((c)->c_flags & CALLOUT_FIRED) hence, my lame claims about the behavior. Sorry for the noise... -reese From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 03:17:09 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E4BD106566B; Mon, 16 Jul 2012 03:17:09 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 725E88FC14; Mon, 16 Jul 2012 03:17:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6G3H9uQ017697; Mon, 16 Jul 2012 03:17:09 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6G3H9bO017693; Mon, 16 Jul 2012 03:17:09 GMT (envelope-from linimon) Date: Mon, 16 Jul 2012 03:17:09 GMT Message-Id: <201207160317.q6G3H9bO017693@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/169898: ifconfig(8) fails to set MTU on multiple interfaces. 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: Mon, 16 Jul 2012 03:17:09 -0000 Synopsis: ifconfig(8) fails to set MTU on multiple interfaces. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jul 16 03:16:57 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=169898 From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 04:31:40 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 B6A3B1065691; Mon, 16 Jul 2012 04:31:40 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 134488FC08; Mon, 16 Jul 2012 04:31:39 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q6G4VVMR044648; Mon, 16 Jul 2012 11:31:32 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <50039923.2060802@rdtc.ru> Date: Mon, 16 Jul 2012 11:31:31 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <20110513162311.GK95084@glebius.int.ru> <4DD298AD.2060905@frasunek.com> <20110517184613.GN74366@glebius.int.ru> <4FDB1D71.6050908@freebsd.lublin.pl> <20120615203142.GW28613@glebius.int.ru> <4FDBAFD7.9020606@freebsd.lublin.pl> <4FDF2F81.6030307@sentex.net> <4FDF3097.6080701@freebsd.lublin.pl> <4FE0EE62.5070905@freebsd.lublin.pl> <4FF7F2C6.5070401@freebsd.lublin.pl> <20120709081225.GJ21957@glebius.int.ru> <4FFBB7A8.90201@rdtc.ru> <4FFBCA96.3000605@freebsd.lublin.pl> <50032E10.3060607@sentex.net> <65702E3D-9373-4CC7-9CB4-81704EF44ED8@lists.zabbadoz.net> In-Reply-To: <65702E3D-9373-4CC7-9CB4-81704EF44ED8@lists.zabbadoz.net> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: Przemyslaw Frasunek , freebsd-net@freebsd.org, Ryan Stone , Mike Tancsa Subject: Re: mpd5/Netgraph issues after upgrading to 7.4 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: Mon, 16 Jul 2012 04:31:40 -0000 16.07.2012 07:13, Bjoern A. Zeeb ΠΙΫΕΤ: > > On 15. Jul 2012, at 20:54 , Mike Tancsa wrote: > >> On 7/10/2012 2:24 AM, Przemyslaw Frasunek wrote: >>>> It seems, Przemyslaw Frasunek uses proxyarp? >>>> I have no such problems but I do not use proxyarp. >>>> Could you get rid of it, Przemyslaw? >>> >>> No, I don't use proxy ARP. I have about 300 PPPoE ng interfaces and 10 VLANs >>> with plain IP traffic. ARP table has only < 50 entries, all of them are dynamic. >> >> I had a new one. Unfortunately, it did not generate a coredump file for >> some reason. Kernel was from ~ mid Feb >> >> Fatal trap 9: general protection fault while in kernel mode >> cpuid = 1; apic id = 02 > ... >> Uptime: 151d12h10m10s >> ipfw: 11 Deny TCP 192.168.1.99:33822 208.47.254.32:80 in via ng471 >> Dumping 883 out of 8145 MB:ipfw: 13 Deny UDP 64.7.157.21:512 >> 192.168.254.46:137 in via ng21 >> panic: bufwrite: buffer is not busy??? >> cpuid = 1 >> Uptime: 151d12h10m10s > > Hmm this one means we didn't stop all CPUs properly on panic; I think that > was fixed since? At least it's the reason you didn't have a chance to get > the core dump. RELENG_8 (and others, perhaps) still needs additional patch (by Andry Gapon) in case of USB keyboard to write crashdump properly. I've sent its URL recently: http://www.grosbein.net/freebsd/patches/stop_scheduler_on_panic.usb.diff > > However of course the initial problem leading to the panic of course > is its own issue still. From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 10:32:36 2012 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 F25811065688 for ; Mon, 16 Jul 2012 10:32:36 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7E61A8FC16 for ; Mon, 16 Jul 2012 10:32:36 +0000 (UTC) Received: by eekb47 with SMTP id b47so129623eek.13 for ; Mon, 16 Jul 2012 03:32:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=ws9ezNNIrAAltWfvaFN7GV3WWXvEXqkad6TeErLATEM=; b=ThfpUNNXTdOwjhibtKWDdzfyKwuHKx8J0WBFatMBgy3sqZz9y4DEPCxB/EjNa4NoJw p6MqgNUzDkvof44zudoEoRV3RGD+BKH6Z3ZkipD+9D6BGfHosSV3p3CBZA80CydTMoQH XufZ08EEKLr53sR2DB370iEMjzN9mq0E/Z5FFA7utTA033Qzq5ltFTgrkOFHXCj9otcz u9OZ53ekYmlVhUZflgVExT0ETW0rFGFERR8HhTHzzZCwmN07i+bjyf5y8SuwtECR8MXs +/ZwVyxr9UeSHDPnZHQmtX7eba33+mShxuawcRUDWGNte2hR376NBNDKWRZ3x5AnPHaS or9g== Received: by 10.14.204.70 with SMTP id g46mr8490914eeo.15.1342434755326; Mon, 16 Jul 2012 03:32:35 -0700 (PDT) Received: from dhcp170-225-red.yandex.net ([2a02:6b8:0:401:706d:8ec4:2f1c:e819]) by mx.google.com with ESMTPS id j4sm17513792eeo.11.2012.07.16.03.32.34 (version=SSLv3 cipher=OTHER); Mon, 16 Jul 2012 03:32:34 -0700 (PDT) Message-ID: <5003EDC4.3050100@zonov.org> Date: Mon, 16 Jul 2012 14:32:36 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnFYs9kBMir1iWvr9cbSEz1ijIog6GqJ3XA9y+bafX1s6gKHDHEit7bJleENq7GCZ2hPZWH Subject: panic: negative refcount 0xfffffe0007f1b4d4 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: Mon, 16 Jul 2012 10:32:37 -0000 Hi, I've got about 30 machines which panic sometimes in different places but with the same panic message: "negative refcount 0xfffffe0007f1b4d4". They are running under 9.0-STABLE@r234600M. Trace looks like this: db:0:kdb.enter.panic> bt Tracing pid 0 tid 100037 td 0xfffffe00074918e0 kdb_enter() at kdb_enter+0x3b panic() at panic+0x180 ifa_free() at ifa_free+0x5d ip_input() at ip_input+0x559 netisr_dispatch_src() at netisr_dispatch_src+0x152 ether_demux() at ether_demux+0x18d ether_nh_input() at ether_nh_input+0x285 netisr_dispatch_src() at netisr_dispatch_src+0x152 em_rxeof() at em_rxeof+0x1a6 em_handle_que() at em_handle_que+0x4c taskqueue_run_locked() at taskqueue_run_locked+0x93 taskqueue_thread_loop() at taskqueue_thread_loop+0x3e fork_exit() at fork_exit+0x135 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000323cb0, rbp = 0 --- or this: db:0:kdb.enter.panic> bt Tracing pid 3502 tid 100175 td 0xfffffe0007fb1470 kdb_enter() at kdb_enter+0x3b panic() at panic+0x180 ifa_free() at ifa_free+0x5d ip_output() at ip_output+0x6ab tcp_output() at tcp_output+0xe40 tcp_usr_connect() at tcp_usr_connect+0x109 soconnect() at soconnect+0x13f kern_connect() at kern_connect+0xde sys_connect() at sys_connect+0x41 amd64_syscall() at amd64_syscall+0x348 Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (98, FreeBSD ELF64, sys_connect), rip = 0x5ecaa93c, rsp = 0x5f99ec78, rbp = 0x5f349c10 --- and I have more. Is this known issue? If it is not, I've got textdumps and can send to anyone who wants to help me. Thanks in advance. -- Andrey Zonov From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 11:09:16 2012 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 36281106564A for ; Mon, 16 Jul 2012 11:09:16 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1B9A08FC14 for ; Mon, 16 Jul 2012 11:09:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6GB9FIY094074 for ; Mon, 16 Jul 2012 11:09:15 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6GB9D1G094069 for freebsd-net@FreeBSD.org; Mon, 16 Jul 2012 11:09:13 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 16 Jul 2012 11:09:13 GMT Message-Id: <201207161109.q6GB9D1G094069@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org 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: Mon, 16 Jul 2012 11:09:16 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169826 net [re] if_re no longer working in 9.x [regression] o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169634 net [bge] Network unavailable when booting directly to Fre o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work o kern/169399 net [re] RealTek RTL8168/8111/8111c network interface not p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/168152 net [xl] Periodically, the network card xl0 stops working o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165863 net [panic] [netinet] [patch] in_lltable_prefix_free() rac o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161381 net [re] RTL8169SC - re0: PHY write failed o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 412 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 17:44:49 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 7FE90106564A; Mon, 16 Jul 2012 17:44:49 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from dhcp170-36-red.yandex.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with ESMTP id 8EA8D15134D; Mon, 16 Jul 2012 17:44:45 +0000 (UTC) Message-ID: <500452A5.3070501@FreeBSD.org> Date: Mon, 16 Jul 2012 21:43:01 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120511 Thunderbird/12.0.1 MIME-Version: 1.0 To: Luigi Rizzo References: <4FF361CA.4000506@FreeBSD.org> <20120703214419.GC92445@onelab2.iet.unipi.it> <4FF36438.2030902@FreeBSD.org> <4FF3E2C4.7050701@FreeBSD.org> <4FF3FB14.8020006@FreeBSD.org> <4FF402D1.4000505@FreeBSD.org> <20120704091241.GA99164@onelab2.iet.unipi.it> <4FF412B9.3000406@FreeBSD.org> <20120704154856.GC3680@onelab2.iet.unipi.it> <4FF59955.5090406@FreeBSD.org> <20120706061126.GA65432@onelab2.iet.unipi.it> In-Reply-To: <20120706061126.GA65432@onelab2.iet.unipi.it> Content-Type: multipart/mixed; boundary="------------040503000001040306070306" Cc: Doug Barton , net@freebsd.org Subject: Re: FreeBSD 10G forwarding performance @Intel 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: Mon, 16 Jul 2012 17:44:49 -0000 This is a multi-part message in MIME format. --------------040503000001040306070306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06.07.2012 10:11, Luigi Rizzo wrote: > On Thu, Jul 05, 2012 at 05:40:37PM +0400, Alexander V. Chernikov wrote: >> On 04.07.2012 19:48, Luigi Rizzo wrote: > the thing discussed a few years ago (at least the one i took out of the > discussion) was that the counter fields in rules should hold the > index of a per-cpu counter associated to the rule. So CTR_INC(rule->ctr) > becomes something like pcpu->ipfw_ctrs[rule->ctr]++ > Once you create a new rule you also grab one free index from ipfw_ctrs[], > and the same should go for dummynet counters. Old kernel from previous letters, same setup: net.inet.ip.fw.enable=0 2.3 MPPS net.inet.ip.fw.update_counters=0 net.inet.ip.fw.enable=1 1.93MPPS net.inet.ip.fw.update_counters=1 1.74MPPS Kernel with ipfw pcpu counters: net.inet.ip.fw.enable=0 2.3 MPPS net.inet.ip.fw.update_counters=0 net.inet.ip.fw.enable=1 1.93MPPS net.inet.ip.fw.update_counters=1 1.93MPPS Counters seems to be working without any (significant) overhead. (Maybe I'm wrong somewhere?) Additionally, I've got (from my previous pcpu attempt) a small patch permitting ipfw to re-use rule map allocation instead of reallocating on every rule. This saves a bit of system time: loading 20k rules with ipfw binary gives us: 5.1s system time before and 4.1s system time after. -- WBR, Alexander --------------040503000001040306070306 Content-Type: text/plain; charset=UTF-8; name="0001-Do-not-allocate-data-buffers-per-each-rule-addition-.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-Do-not-allocate-data-buffers-per-each-rule-addition-.pa"; filename*1="tch" >From 931ac84b88829fe15bb4410bd2b06614f41c99b5 Mon Sep 17 00:00:00 2001 From: "Alexander V. Chernikov" Date: Mon, 9 Jul 2012 23:10:02 +0400 Subject: [PATCH 1/3] Do not allocate data buffers per each rule addition/deletion --- sys/netinet/ipfw/ip_fw2.c | 2 + sys/netinet/ipfw/ip_fw_private.h | 4 ++ sys/netinet/ipfw/ip_fw_sockopt.c | 134 ++++++++++++++++++++++++++++++++++---- 3 files changed, 126 insertions(+), 14 deletions(-) diff --git a/sys/netinet/ipfw/ip_fw2.c b/sys/netinet/ipfw/ip_fw2.c index 98766f3..bf06c1e 100644 --- a/sys/netinet/ipfw/ip_fw2.c +++ b/sys/netinet/ipfw/ip_fw2.c @@ -2701,6 +2701,8 @@ vnet_ipfw_uninit(const void *unused) } if (chain->map) free(chain->map, M_IPFW); + if (chain->b_map) + free(chain->b_map, M_IPFW); IPFW_WUNLOCK(chain); IPFW_UH_WUNLOCK(chain); if (reap != NULL) diff --git a/sys/netinet/ipfw/ip_fw_private.h b/sys/netinet/ipfw/ip_fw_private.h index 2806741..272cef3 100644 --- a/sys/netinet/ipfw/ip_fw_private.h +++ b/sys/netinet/ipfw/ip_fw_private.h @@ -232,6 +232,10 @@ struct ip_fw_chain { #endif uint32_t id; /* ruleset id */ uint32_t gencnt; /* generation count */ + int n_allocated; /* Size of primary map in items */ + struct ip_fw **b_map; /* Backup map to use in swapping */ + int b_allocated; /* Size of backup map in items */ + }; struct sockopt; /* used by tcp_var.h */ diff --git a/sys/netinet/ipfw/ip_fw_sockopt.c b/sys/netinet/ipfw/ip_fw_sockopt.c index a245143..4e71a11 100644 --- a/sys/netinet/ipfw/ip_fw_sockopt.c +++ b/sys/netinet/ipfw/ip_fw_sockopt.c @@ -97,29 +97,92 @@ ipfw_find_rule(struct ip_fw_chain *chain, uint32_t key, uint32_t id) return hi; } + + +/* + * In order to minimize block allocations on every rule addition we + * use the following technique: + * 1) round up allocation to MAP_GRANULARITY + * 2) Save previously allocated map to the special bakup pointer. + * + * This permits us do backup <> primary (and vise versa) map swapping + * without reallocations in most cases. + * + */ + +struct map_ptrs { + int backup; /* 1 if backup map used */ + int items; /* number of items allocated */ + struct ip_fw **map; + struct ip_fw **free_map; /* map pointer to free */ +}; +int +get_map(struct ip_fw_chain *chain, int extra, int locked, struct map_ptrs *ptrs); + +#define MAP_GRANULARITY 128 /* 1k overhead per buffer */ +#define MAP_ROUNDUP(i) (i) + MAP_GRANULARITY - ((i) % MAP_GRANULARITY) /* * allocate a new map, returns the chain locked. extra is the number * of entries to add or delete. */ -static struct ip_fw ** -get_map(struct ip_fw_chain *chain, int extra, int locked) +int +get_map(struct ip_fw_chain *chain, int extra, int locked, struct map_ptrs *ptrs) { for (;;) { struct ip_fw **map; int i; + /* Be optimistic by default */ + if (!locked) + IPFW_UH_WLOCK(chain); + i = chain->n_rules + extra; + + /* + * We have to fit to the following conditions in order + * to use backup map: + * + * 1) i <= chain->b_allocated (add case) + * 2) roundup(i) == chain->b_allocated (del case) (saves memory) + * + * Since roundup adds 0..(MAP_GRANULARITY-1) + * rule 2 requires rule 1 to be true. + */ + CTR4(KTR_NET, "%s: req: %d roundup: %d, b_allocated: %d", + __func__, i, MAP_ROUNDUP(i), chain->b_allocated); + + if (MAP_ROUNDUP(i) == chain->b_allocated) { + /* no new allocation. Just return backup map */ + ptrs->backup = 1; + ptrs->items = chain->b_allocated; + ptrs->map = chain->b_map; + CTR3(KTR_NET, "%s: BACKUP SELECTED: %p items: %d", __func__, ptrs->map, ptrs->items); + + return 1; + } + + /* Pessimistic scenario - we need reallocation */ + i = MAP_ROUNDUP(i); + + if (!locked) + IPFW_UH_WUNLOCK(chain); + map = malloc(i * sizeof(struct ip_fw *), M_IPFW, locked ? M_NOWAIT : M_WAITOK); if (map == NULL) { printf("%s: cannot allocate map\n", __FUNCTION__); - return NULL; + return 0; } if (!locked) IPFW_UH_WLOCK(chain); - if (i >= chain->n_rules + extra) /* good */ - return map; + if (i >= chain->n_rules + extra) { /* good */ + ptrs->backup = 0; + ptrs->items = i; + ptrs->map = map; + CTR3(KTR_NET, "%s: NEW MAP: %p items: %d", __func__, ptrs->map, ptrs->items); + return 1; + } /* otherwise we lost the race, free and retry */ if (!locked) IPFW_UH_WUNLOCK(chain); @@ -128,10 +191,11 @@ get_map(struct ip_fw_chain *chain, int extra, int locked) } /* - * swap the maps. It is supposed to be called with IPFW_UH_WLOCK + * swap the maps. It is supposed to be called with IPFW_UH_WLOCK. + * Returns old map pointer to free. */ static struct ip_fw ** -swap_map(struct ip_fw_chain *chain, struct ip_fw **new_map, int new_len) +swap_map(struct ip_fw_chain *chain, struct map_ptrs *ptrs, int new_len) { struct ip_fw **old_map; @@ -139,8 +203,43 @@ swap_map(struct ip_fw_chain *chain, struct ip_fw **new_map, int new_len) chain->id++; chain->n_rules = new_len; old_map = chain->map; - chain->map = new_map; + chain->map = ptrs->map; IPFW_WUNLOCK(chain); + + CTR4(KTR_NET, "%s: old: %p new: %p, backup: %d", + __func__, old_map, chain->map, ptrs->backup); + + /* Finalize map change */ + if (ptrs->backup) { + /* + * Old map has (at least) the same size as current map. + * Save it as backup map. + */ + chain->b_allocated = chain->n_allocated; + chain->n_allocated = ptrs->items; + chain->b_map = old_map; + ptrs->free_map = NULL; + return old_map; + } + + /* + * Backup map is not used. Free old map and use + * current map as candidate. + */ + + /* Set free pointer to old backup map */ + ptrs->free_map = chain->b_map; + /* Set backup map to be old current map */ + chain->b_map = old_map; + + /* Save backup map size */ + chain->b_allocated = chain->n_allocated; + chain->n_allocated = ptrs->items; + + CTR6(KTR_NET, "%s: new: %p alloc: %d backup: %p alloc: %d free: %p", + __func__, chain->map, chain->n_allocated, + chain->b_map, chain->b_allocated, ptrs->free_map); + return old_map; } @@ -156,6 +255,7 @@ ipfw_add_rule(struct ip_fw_chain *chain, struct ip_fw *input_rule) { struct ip_fw *rule; int i, l, insert_before; + struct map_ptrs ptrs; struct ip_fw **map; /* the new array of pointers */ if (chain->rules == NULL || input_rule->rulenum > IPFW_DEFAULT_RULE-1) @@ -164,12 +264,13 @@ ipfw_add_rule(struct ip_fw_chain *chain, struct ip_fw *input_rule) l = RULESIZE(input_rule); rule = malloc(l, M_IPFW, M_WAITOK | M_ZERO); /* get_map returns with IPFW_UH_WLOCK if successful */ - map = get_map(chain, 1, 0 /* not locked */); - if (map == NULL) { + if (get_map(chain, 1, 0 /* not locked */, &ptrs) == 0) { free(rule, M_IPFW); return ENOSPC; } + map = ptrs.map; + bcopy(input_rule, rule, l); /* clear fields not settable from userland */ rule->x_next = NULL; @@ -201,7 +302,8 @@ ipfw_add_rule(struct ip_fw_chain *chain, struct ip_fw *input_rule) } rule->id = chain->id + 1; - map = swap_map(chain, map, chain->n_rules + 1); + swap_map(chain, &ptrs, chain->n_rules + 1); + map = ptrs.free_map; chain->static_len += l; IPFW_UH_WUNLOCK(chain); if (map) @@ -283,6 +385,7 @@ del_entry(struct ip_fw_chain *chain, uint32_t arg) uint32_t num; /* rule number or old_set */ uint8_t cmd, new_set; int start, end, i, ofs, n; + struct map_ptrs ptrs; struct ip_fw **map = NULL; int error = 0; @@ -353,12 +456,13 @@ del_entry(struct ip_fw_chain *chain, uint32_t arg) } /* We have something to delete. Allocate the new map */ - map = get_map(chain, -n, 1 /* locked */); - if (map == NULL) { + if (get_map(chain, -n, 1 /* locked */, &ptrs) == 0) { error = EINVAL; break; } + map = ptrs.map; + /* 1. bcopy the initial part of the map */ if (start > 0) bcopy(chain->map, map, start * sizeof(struct ip_fw *)); @@ -372,7 +476,7 @@ del_entry(struct ip_fw_chain *chain, uint32_t arg) bcopy(chain->map + end, map + ofs, (chain->n_rules - end) * sizeof(struct ip_fw *)); /* 4. swap the maps (under BH_LOCK) */ - map = swap_map(chain, map, chain->n_rules - n); + map = swap_map(chain, &ptrs, chain->n_rules - n); /* 5. now remove the rules deleted from the old map */ for (i = start; i < end; i++) { int l; @@ -385,6 +489,8 @@ del_entry(struct ip_fw_chain *chain, uint32_t arg) rule->x_next = chain->reap; chain->reap = rule; } + /* Free map if we need to */ + map = ptrs.free_map; break; /* -- 1.7.9.4 --------------040503000001040306070306 Content-Type: text/plain; charset=UTF-8; name="0001-Make-accounting-in-ipfw-optional.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Make-accounting-in-ipfw-optional.patch" >From baad4a88bba898baa3aa5f0dffc8a40182bcfcd6 Mon Sep 17 00:00:00 2001 From: Charlie Root Date: Thu, 12 Jul 2012 17:19:10 +0000 Subject: [PATCH 1/2] Make accounting in ipfw optional --- sys/netinet/ipfw/ip_fw2.c | 32 +++++++++++++++++++++----------- 1 files changed, 21 insertions(+), 11 deletions(-) diff --git a/sys/netinet/ipfw/ip_fw2.c b/sys/netinet/ipfw/ip_fw2.c index e5a13e4..7bb73b0 100644 --- a/sys/netinet/ipfw/ip_fw2.c +++ b/sys/netinet/ipfw/ip_fw2.c @@ -112,6 +112,8 @@ static int default_to_accept = 1; static int default_to_accept; #endif +static int update_counters = 0; + VNET_DEFINE(int, autoinc_step); VNET_DEFINE(unsigned int, fw_tables_max); @@ -190,6 +192,8 @@ SYSCTL_VNET_INT(_net_inet6_ip6_fw, OID_AUTO, permit_single_frag6, "Permit single packet IPv6 fragments"); #endif /* INET6 */ +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, update_counters, CTLFLAG_RW, + &update_counters, 0, "Update counters on match"); SYSEND #endif /* SYSCTL_NODE */ @@ -2011,16 +2015,20 @@ do { \ break; case O_COUNT: - f->pcnt++; /* update stats */ - f->bcnt += pktlen; - f->timestamp = time_uptime; + if (update_counters) { + f->pcnt++; /* update stats */ + f->bcnt += pktlen; + f->timestamp = time_uptime; + } l = 0; /* exit inner loop */ break; case O_SKIPTO: - f->pcnt++; /* update stats */ - f->bcnt += pktlen; - f->timestamp = time_uptime; + if (update_counters) { + f->pcnt++; /* update stats */ + f->bcnt += pktlen; + f->timestamp = time_uptime; + } /* If possible use cached f_pos (in f->next_rule), * whose version is written in f->next_rule * (horrible hacks to avoid changing the ABI). @@ -2375,11 +2383,13 @@ do { \ } /* end of outer for, scan rules */ if (done) { - struct ip_fw *rule = chain->map[f_pos]; - /* Update statistics */ - rule->pcnt++; - rule->bcnt += pktlen; - rule->timestamp = time_uptime; + if (update_counters) { + struct ip_fw *rule = chain->map[f_pos]; + /* Update statistics */ + rule->pcnt++; + rule->bcnt += pktlen; + rule->timestamp = time_uptime; + } } else { retval = IP_FW_DENY; printf("ipfw: ouch!, skip past end of rules, denying packet\n"); -- 1.7.6.1 --------------040503000001040306070306 Content-Type: text/plain; charset=UTF-8; name="ipfw_pcpu_8.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ipfw_pcpu_8.diff" diff --git a/sys/netinet/ip_fw.h b/sys/netinet/ip_fw.h index 589c19c..b1f83bb 100644 --- a/sys/netinet/ip_fw.h +++ b/sys/netinet/ip_fw.h @@ -493,9 +493,14 @@ struct ip_fw { uint32_t id; /* rule id */ /* These fields are present in all rules. */ +#if 0 uint64_t pcnt; /* Packet counter */ uint64_t bcnt; /* Byte counter */ uint32_t timestamp; /* tv_sec of last match */ +#endif + uint64_t _pad0; + uint64_t _pad1; + uint32_t cntr_idx; /* Index in pcpu counters */ ipfw_insn cmd[1]; /* storage for commands */ }; diff --git a/sys/netinet/ipfw/ip_fw2.c b/sys/netinet/ipfw/ip_fw2.c index 7bb73b0..db93a5c 100644 --- a/sys/netinet/ipfw/ip_fw2.c +++ b/sys/netinet/ipfw/ip_fw2.c @@ -2016,18 +2016,20 @@ do { \ case O_COUNT: if (update_counters) { - f->pcnt++; /* update stats */ - f->bcnt += pktlen; - f->timestamp = time_uptime; + struct ip_fw_cntr *c = IPFW_PCPU_CNTR(chain, f->cntr_idx); + c->pcnt++; /* update stats */ + c->bcnt += pktlen; + c->timestamp = time_uptime; } l = 0; /* exit inner loop */ break; case O_SKIPTO: if (update_counters) { - f->pcnt++; /* update stats */ - f->bcnt += pktlen; - f->timestamp = time_uptime; + struct ip_fw_cntr *c = IPFW_PCPU_CNTR(chain, f->cntr_idx); + c->pcnt++; /* update stats */ + c->bcnt += pktlen; + c->timestamp = time_uptime; } /* If possible use cached f_pos (in f->next_rule), * whose version is written in f->next_rule @@ -2125,9 +2127,10 @@ do { \ break; } - f->pcnt++; /* update stats */ - f->bcnt += pktlen; - f->timestamp = time_uptime; + struct ip_fw_cntr *c = IPFW_PCPU_CNTR(chain, f->cntr_idx); + c->pcnt++; /* update stats */ + c->bcnt += pktlen; + c->timestamp = time_uptime; stack = (uint16_t *)(mtag + 1); /* @@ -2263,9 +2266,10 @@ do { \ case O_SETFIB: { uint32_t fib; - f->pcnt++; /* update stats */ - f->bcnt += pktlen; - f->timestamp = time_uptime; + struct ip_fw_cntr *c = IPFW_PCPU_CNTR(chain, f->cntr_idx); + c->pcnt++; /* update stats */ + c->bcnt += pktlen; + c->timestamp = time_uptime; fib = (cmd->arg1 == IP_FW_TABLEARG) ? tablearg: cmd->arg1; if (fib >= rt_numfibs) @@ -2315,8 +2319,9 @@ do { \ case O_REASS: { int ip_off; - f->pcnt++; - f->bcnt += pktlen; + struct ip_fw_cntr *c = IPFW_PCPU_CNTR(chain, f->cntr_idx); + c->pcnt++; + c->bcnt += pktlen; l = 0; /* in any case exit inner loop */ ip_off = ntohs(ip->ip_off); @@ -2386,9 +2391,10 @@ do { \ if (update_counters) { struct ip_fw *rule = chain->map[f_pos]; /* Update statistics */ - rule->pcnt++; - rule->bcnt += pktlen; - rule->timestamp = time_uptime; + struct ip_fw_cntr *c = IPFW_PCPU_CNTR(chain, rule->cntr_idx); + c->pcnt++; + c->bcnt += pktlen; + c->timestamp = time_uptime; } } else { retval = IP_FW_DENY; @@ -2439,6 +2445,7 @@ ipfw_init(void) { int error = 0; + _dpcpu_init(); ipfw_dyn_attach(); /* * Only print out this stuff the first time around, @@ -2500,6 +2507,7 @@ ipfw_destroy(void) ipfw_log_bpf(0); /* uninit */ ipfw_dyn_detach(); + _dpcpu_uninit(); printf("IP firewall unloaded\n"); } @@ -2546,6 +2554,9 @@ vnet_ipfw_init(const void *unused) return (ENOSPC); } + /* Init per-cpu counters */ + ipfw_init_counters(chain); + /* fill and insert the default rule */ rule->act_ofs = 0; rule->rulenum = IPFW_DEFAULT_RULE; @@ -2559,6 +2570,9 @@ vnet_ipfw_init(const void *unused) IPFW_LOCK_INIT(chain); ipfw_dyn_init(); + /* Allocate first pcpu counter */ + rule->cntr_idx = ipfw_alloc_counter(chain); + /* First set up some values that are compile time options */ V_ipfw_vnet_ready = 1; /* Open for business */ @@ -2619,10 +2633,11 @@ vnet_ipfw_uninit(const void *unused) } if (chain->map) free(chain->map, M_IPFW); + _dpcpu_free(chain->cntrs); IPFW_WUNLOCK(chain); IPFW_UH_WUNLOCK(chain); if (reap != NULL) - ipfw_reap_rules(reap); + ipfw_reap_rules(chain, reap); IPFW_LOCK_DESTROY(chain); ipfw_dyn_uninit(1); /* free the remaining parts */ return 0; diff --git a/sys/netinet/ipfw/ip_fw_private.h b/sys/netinet/ipfw/ip_fw_private.h index 46d011c..bd4fad3 100644 --- a/sys/netinet/ipfw/ip_fw_private.h +++ b/sys/netinet/ipfw/ip_fw_private.h @@ -222,6 +222,7 @@ struct ip_fw_chain { struct radix_node_head **tables; /* IPv4 tables */ struct radix_node_head **xtables; /* extended tables */ uint8_t *tabletype; /* Array of table types */ + uintptr_t *cntrs; /* Per-cpu counters */ #if defined( __linux__ ) || defined( _WIN32 ) spinlock_t rwmtx; spinlock_t uh_lock; @@ -231,8 +232,25 @@ struct ip_fw_chain { #endif uint32_t id; /* ruleset id */ uint32_t gencnt; /* generation count */ + int cntr_allocated; /* Size of allocated counters map */ + uint32_t *cntr_idx; /* bit index of counters map */ }; +struct ip_fw_cntr { + uint64_t pcnt; /* Packet counter */ + uint64_t bcnt; /* Byte counter */ + uint32_t timestamp; /* tv_sec of last match */ +}; +#define IPFW_PCPU_CNTR(chain, idx) ((struct ip_fw_cntr *)(chain)->cntrs[curcpu] + idx) +#define IPFW_PCPU_DEFAULT_COUNTERS 128 +void _dpcpu_init(void); +void _dpcpu_uninit(void); +uintptr_t *_dpcpu_alloc(size_t size, int flags); +void _dpcpu_free(uintptr_t *ptr); +void ipfw_init_counters(struct ip_fw_chain *chain); +int ipfw_alloc_counter(struct ip_fw_chain *chain); +void ipfw_free_counter(struct ip_fw_chain *chain, int idx); + struct sockopt; /* used by tcp_var.h */ /* @@ -267,7 +285,10 @@ int ipfw_find_rule(struct ip_fw_chain *chain, uint32_t key, uint32_t id); int ipfw_add_rule(struct ip_fw_chain *chain, struct ip_fw *input_rule); int ipfw_ctl(struct sockopt *sopt); int ipfw_chk(struct ip_fw_args *args); -void ipfw_reap_rules(struct ip_fw *head); +void ipfw_reap_rules(struct ip_fw_chain *chain, struct ip_fw *head); + +void ipfw_zero_counter(struct ip_fw_chain *chain, int idx); +void ipfw_export_counter(struct ip_fw_chain *chain, int idx, struct ip_fw_cntr *cntr); /* In ip_fw_pfil */ int ipfw_check_hook(void *arg, struct mbuf **m0, struct ifnet *ifp, int dir, diff --git a/sys/netinet/ipfw/ip_fw_sockopt.c b/sys/netinet/ipfw/ip_fw_sockopt.c index 0aecc2c..db308c2 100644 --- a/sys/netinet/ipfw/ip_fw_sockopt.c +++ b/sys/netinet/ipfw/ip_fw_sockopt.c @@ -45,6 +45,7 @@ __FBSDID("$FreeBSD$"); #include #include /* struct m_tag used by nested headers */ #include +#include #include #include #include @@ -72,6 +73,212 @@ MALLOC_DEFINE(M_IPFW, "IpFw/IpAcct", "IpFw/IpAcct chain's"); * static variables followed by global ones (none in this file) */ +MALLOC_DEFINE(M_XDPCPU, "XPCPU", "PCPU data"); + +uma_zone_t _dpcpu_zone; + +static void ipfw_extend_counters(struct ip_fw_chain *chain); + +void +_dpcpu_init() +{ + _dpcpu_zone = uma_zcreate("pcpu ptrs", sizeof(uintptr_t) * MAXCPU, + NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, 0); +} + +void +_dpcpu_uninit() +{ + uma_zdestroy(_dpcpu_zone); +} + +#define _DPCPU_ALIGN 512 +uintptr_t * +_dpcpu_alloc(size_t size, int flags) +{ + uintptr_t *ptr; + int id, fail = 0; + + if (size % _DPCPU_ALIGN) + size += _DPCPU_ALIGN - (size % _DPCPU_ALIGN); + + if ((ptr = uma_zalloc(_dpcpu_zone, flags | M_ZERO)) == NULL) + return NULL; + + CPU_FOREACH(id) { + /* + * We believe in aligned allocation here + */ + if ((ptr[id] = (uintptr_t)malloc(size, M_XDPCPU, flags)) == 0) { + fail = 1; + break; + } + + KASSERT((uintptr_t)ptr % _DPCPU_ALIGN == 0, ("malloc(9) returns unaligned data :(")); + } + + if (fail == 0) + return ptr; + + CPU_FOREACH(id) { + if (ptr[id] == 0) + break; + + free((void *)ptr[id], M_XDPCPU); + } + + uma_zfree(_dpcpu_zone, ptr); + + return NULL; +} + +void +_dpcpu_free(uintptr_t *ptr) +{ + int id; + + CPU_FOREACH(id) { + if (ptr[id] == 0) + continue; + free((void *)ptr[id], M_XDPCPU); + } + + uma_zfree(_dpcpu_zone, ptr); +} + +void +ipfw_init_counters(struct ip_fw_chain *chain) +{ + chain->cntrs = _dpcpu_alloc(IPFW_PCPU_DEFAULT_COUNTERS * + sizeof(struct ip_fw_cntr), M_WAITOK | M_ZERO); + chain->cntr_idx = malloc(IPFW_PCPU_DEFAULT_COUNTERS / 8, M_IPFW, M_WAITOK); + /* Free positions are marked by 1 */ + memset(chain->cntr_idx, 0xFF, IPFW_PCPU_DEFAULT_COUNTERS / 8); + chain->cntr_allocated = IPFW_PCPU_DEFAULT_COUNTERS; +} + + +static void +ipfw_extend_counters(struct ip_fw_chain *chain) +{ + uintptr_t *new_ptr, *old_ptr; + uint32_t *old_idx, *new_idx; + int i, id; + + for (;;) { + + i = 2 * chain->cntr_allocated; + + new_ptr = _dpcpu_alloc(i * sizeof(struct ip_fw_cntr), M_WAITOK | M_ZERO); + new_idx = malloc(i / 8, M_IPFW, M_WAITOK); + /* Free positions are marked by 1 */ + memset(new_idx, 0xFF, i / 8); + + IPFW_UH_WLOCK(chain); + if (i == 2 * chain->cntr_allocated) { + CTR4(KTR_NET, "%s: NEW INDEX: %p cntr_idx: %d count: %d", __func__, new_ptr, new_idx, i); + break; + } + /* otherwise we lost the race, free and retry */ + IPFW_UH_WUNLOCK(chain); + + free(new_idx, M_IPFW); + _dpcpu_free(new_ptr); + } + + /* Pointers allocated, let's migrate data */ + + IPFW_WLOCK(chain); + /* Copy pcpu counters */ + CPU_FOREACH(id) { + memcpy((void *)new_ptr[id], (void *)chain->cntrs[id], chain->cntr_allocated * sizeof(struct ip_fw_cntr)); + } + /* Copy index */ + memcpy(new_idx, chain->cntr_idx, chain->cntr_allocated / 8); + /* Swap old and new pointers */ + old_ptr = chain->cntrs; + chain->cntrs = new_ptr; + old_idx = chain->cntr_idx; + chain->cntr_idx = new_idx; + chain->cntr_allocated = i; + + IPFW_WUNLOCK(chain); + IPFW_UH_WUNLOCK(chain); + + /* Free old counters and index */ + free(old_idx, M_IPFW); + _dpcpu_free(old_ptr); +} + +int +ipfw_alloc_counter(struct ip_fw_chain *chain) +{ + int i, x, idx; + uint32_t *v; + + for (;;) { + IPFW_UH_WLOCK(chain); + for (i = 0, v = chain->cntr_idx; i < chain->cntr_allocated / 8 / 4; i++, v++) { + if ((x = ffsl(*v)) != 0) { + /* Found. Mark as used */ + *v &= ~ (1 << (x - 1)); + IPFW_UH_WUNLOCK(chain); + idx = i * 32 + x - 1; + ipfw_zero_counter(chain, idx); + CTR3(KTR_NET, "%s: allocated counter %d, map after: %X", __func__, idx, *v); + return idx; + } + } + IPFW_UH_WUNLOCK(chain); + + /* Not found. Let's allocate data and retry */ + ipfw_extend_counters(chain); + } +} + +void +ipfw_free_counter(struct ip_fw_chain *chain, int idx) +{ + uint32_t *v; + + IPFW_UH_WLOCK(chain); + v = chain->cntr_idx; + v += idx / 32; + CTR3(KTR_NET, "%s: returned counter %d, map before: %X", __func__, idx, *v); + idx %= 32; + *v |= 1 << idx; + + IPFW_UH_WUNLOCK(chain); +} + +void +ipfw_zero_counter(struct ip_fw_chain *chain, int idx) +{ + int id; + struct ip_fw_cntr *pcpu; + + CTR2(KTR_NET, "%s: zeroing counter %d", __func__, idx); + CPU_FOREACH(id) { + pcpu = ((struct ip_fw_cntr *)chain->cntrs[id]) + idx; + memset(pcpu, 0, sizeof(struct ip_fw_cntr)); + } +} + +void +ipfw_export_counter(struct ip_fw_chain *chain, int idx, struct ip_fw_cntr *cntr) +{ + int id; + struct ip_fw_cntr *pcpu; + + CPU_FOREACH(id) { + pcpu = ((struct ip_fw_cntr *)chain->cntrs[id]) + idx; + cntr->pcnt += pcpu->pcnt; + cntr->bcnt += pcpu->bcnt; + if (cntr->timestamp < pcpu->timestamp) + cntr->timestamp = pcpu->timestamp; + } +} + /* * Find the smallest rule >= key, id. * We could use bsearch but it is so simple that we code it directly @@ -155,7 +362,7 @@ int ipfw_add_rule(struct ip_fw_chain *chain, struct ip_fw *input_rule) { struct ip_fw *rule; - int i, l, insert_before; + int i, l, cntr_idx, insert_before; struct ip_fw **map; /* the new array of pointers */ if (chain->rules == NULL || input_rule->rulenum > IPFW_DEFAULT_RULE-1) @@ -163,12 +370,14 @@ ipfw_add_rule(struct ip_fw_chain *chain, struct ip_fw *input_rule) l = RULESIZE(input_rule); rule = malloc(l, M_IPFW, M_WAITOK | M_ZERO); + cntr_idx = ipfw_alloc_counter(chain); if (rule == NULL) return (ENOSPC); /* get_map returns with IPFW_UH_WLOCK if successful */ map = get_map(chain, 1, 0 /* not locked */); if (map == NULL) { free(rule, M_IPFW); + ipfw_free_counter(chain, cntr_idx); return ENOSPC; } @@ -176,10 +385,12 @@ ipfw_add_rule(struct ip_fw_chain *chain, struct ip_fw *input_rule) /* clear fields not settable from userland */ rule->x_next = NULL; rule->next_rule = NULL; + rule->cntr_idx = cntr_idx; +#if 0 rule->pcnt = 0; rule->bcnt = 0; rule->timestamp = 0; - +#endif if (V_autoinc_step < 1) V_autoinc_step = 1; else if (V_autoinc_step > 1000) @@ -217,12 +428,13 @@ ipfw_add_rule(struct ip_fw_chain *chain, struct ip_fw *input_rule) * A NULL pointer on input is handled correctly. */ void -ipfw_reap_rules(struct ip_fw *head) +ipfw_reap_rules(struct ip_fw_chain *chain, struct ip_fw *head) { struct ip_fw *rule; while ((rule = head) != NULL) { head = head->x_next; + ipfw_free_counter(chain, rule->cntr_idx); free(rule, M_IPFW); } } @@ -424,7 +636,7 @@ del_entry(struct ip_fw_chain *chain, uint32_t arg) rule = chain->reap; chain->reap = NULL; IPFW_UH_WUNLOCK(chain); - ipfw_reap_rules(rule); + ipfw_reap_rules(chain, rule); if (map) free(map, M_IPFW); return error; @@ -436,13 +648,17 @@ del_entry(struct ip_fw_chain *chain, uint32_t arg) * so we only care that rules do not disappear. */ static void -clear_counters(struct ip_fw *rule, int log_only) +clear_counters(struct ip_fw_chain *chain, struct ip_fw *rule, int log_only) { ipfw_insn_log *l = (ipfw_insn_log *)ACTION_PTR(rule); if (log_only == 0) { +#if 0 rule->bcnt = rule->pcnt = 0; rule->timestamp = 0; +#endif + ipfw_zero_counter(chain, rule->cntr_idx); + } if (l->o.opcode == O_LOG) l->log_left = l->max_log; @@ -481,7 +697,7 @@ zero_entry(struct ip_fw_chain *chain, u_int32_t arg, int log_only) /* Skip rules not in our set. */ if (cmd == 1 && rule->set != set) continue; - clear_counters(rule, log_only); + clear_counters(chain, rule, log_only); } msg = log_only ? "All logging counts reset" : "Accounting cleared"; @@ -491,7 +707,7 @@ zero_entry(struct ip_fw_chain *chain, u_int32_t arg, int log_only) rule = chain->map[i]; if (rule->rulenum == rulenum) { if (cmd == 0 || rule->set == set) - clear_counters(rule, log_only); + clear_counters(chain, rule, log_only); cleared = 1; } if (rule->rulenum > rulenum) @@ -854,7 +1070,7 @@ struct ip_fw7 { ipfw_insn cmd[1]; /* storage for commands */ }; - int convert_rule_to_7(struct ip_fw *rule); +int convert_rule_to_7(struct ip_fw_chain *chain, struct ip_fw *rule); int convert_rule_to_8(struct ip_fw *rule); #ifndef RULESIZE7 @@ -887,7 +1103,7 @@ ipfw_getrules(struct ip_fw_chain *chain, void *buf, size_t space) if (bp + l + sizeof(uint32_t) <= ep) { int error; bcopy(rule, bp, l + sizeof(uint32_t)); - error = convert_rule_to_7((struct ip_fw *) bp); + error = convert_rule_to_7(chain, (struct ip_fw *) bp); if (error) return 0; /*XXX correct? */ /* @@ -913,14 +1129,19 @@ ipfw_getrules(struct ip_fw_chain *chain, void *buf, size_t space) } dst = (struct ip_fw *)bp; bcopy(rule, dst, l); + /* copy statistics */ + struct ip_fw_cntr *c = (struct ip_fw_cntr *)&dst->_pad0; + ipfw_export_counter(chain, rule->cntr_idx, c); + if (c->timestamp) + c->timestamp += boot_seconds; + /* * XXX HACK. Store the disable mask in the "next" * pointer in a wild attempt to keep the ABI the same. * Why do we do this on EVERY rule? */ bcopy(&V_set_disable, &dst->next_rule, sizeof(V_set_disable)); - if (dst->timestamp) - dst->timestamp += boot_seconds; + bp += l; } ipfw_get_dynamic(&bp, ep); /* protected by the dynamic lock */ @@ -1051,7 +1272,7 @@ ipfw_ctl(struct sockopt *sopt) size = RULESIZE(rule); if (!error && sopt->sopt_dir == SOPT_GET) { if (is7) { - error = convert_rule_to_7(rule); + error = convert_rule_to_7(chain, rule); size = RULESIZE7(rule); if (error) return error; @@ -1329,7 +1550,7 @@ ipfw_ctl(struct sockopt *sopt) /* Functions to convert rules 7.2 <==> 8.0 */ int -convert_rule_to_7(struct ip_fw *rule) +convert_rule_to_7(struct ip_fw_chain *chain, struct ip_fw *rule) { /* Used to modify original rule */ struct ip_fw7 *rule7 = (struct ip_fw7 *)rule; @@ -1355,9 +1576,12 @@ convert_rule_to_7(struct ip_fw *rule) rule7->next_rule = (struct ip_fw7 *)tmp->next_rule; rule7->next = (struct ip_fw7 *)tmp->x_next; rule7->cmd_len = tmp->cmd_len; + ipfw_export_counter(chain, rule->cntr_idx, (struct ip_fw_cntr *)&rule7->pcnt); +#if 0 rule7->pcnt = tmp->pcnt; rule7->bcnt = tmp->bcnt; rule7->timestamp = tmp->timestamp; +#endif /* Copy commands */ for (ll = tmp->cmd_len, ccmd = tmp->cmd, dst = rule7->cmd ; @@ -1429,10 +1653,11 @@ convert_rule_to_8(struct ip_fw *rule) rule->x_next = (struct ip_fw *)tmp->next; rule->cmd_len = tmp->cmd_len; rule->id = 0; /* XXX see if is ok = 0 */ +#if 0 rule->pcnt = tmp->pcnt; rule->bcnt = tmp->bcnt; rule->timestamp = tmp->timestamp; - +#endif free (tmp, M_TEMP); return 0; } --------------040503000001040306070306-- From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 19:49:26 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CCA31065673 for ; Mon, 16 Jul 2012 19:49:26 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id A54CD8FC08 for ; Mon, 16 Jul 2012 19:49:25 +0000 (UTC) Received: (qmail 24980 invoked from network); 16 Jul 2012 21:45:22 -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 ; 16 Jul 2012 21:45:22 -0000 Message-ID: <50047040.5040506@networx.ch> Date: Mon, 16 Jul 2012 21:49:20 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: George Neville-Neil References: <86liiqrnnq.wl%gnn@neville-neil.com> <4FFDF6C7.3030301@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Navdeep Parhar , net@freebsd.org Subject: Re: Interface MTU question... 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: Mon, 16 Jul 2012 19:49:26 -0000 On 12.07.2012 16:55, George Neville-Neil wrote: > > On Jul 11, 2012, at 17:57 , Navdeep Parhar wrote: > >> On 07/11/12 14:30, gnn@freebsd.org wrote: >>> Howdy, >>> >>> Does anyone know the reason for this particular check in >>> ip_output.c? >>> >>> if (rte != NULL && (rte->rt_flags & (RTF_UP|RTF_HOST))) { >>> /* >>> * This case can happen if the user changed the MTU >>> * of an interface after enabling IP on it. Because >>> * most netifs don't keep track of routes pointing to >>> * them, there is no way for one to update all its >>> * routes when the MTU is changed. >>> */ >>> if (rte->rt_rmx.rmx_mtu > ifp->if_mtu) >>> rte->rt_rmx.rmx_mtu = ifp->if_mtu; >>> mtu = rte->rt_rmx.rmx_mtu; >>> } else { >>> mtu = ifp->if_mtu; >>> } >>> >>> To my mind the > ought to be != so that any change, up or down, of the >>> interface MTU is eventually reflected in the route. Also, this code >>> does not check if it is both a HOST route and UP, but only if it is >>> one other the other, so don't be fooled by that, this check happens >>> for any route we have if it's up. >> >> I believe rmx_mtu could be low due to some intermediate node between this host and the final destination. An increase in the MTU of the local interface should not increase the path MTU if the limit was due to someone else along the route. > > Yes, it turns out to be complex. We have several places that store the MTU. There is the interface, > which knows the MTU of the directly connected link, a route, and the host cache. All three of these > are used to determine the maximum segment size (MSS) of a TCP packet. The route and the interface > determine the maximum MTU that the MSS can have, but, if there is an entry in the host cache > then it is preferred over either of the first two. See tcp_update_mss() in tcp_input.c to > see what I'm talking about. We have three sources of the MTU for TCP to chose from (sorted in priority order): 1. Hostcache to use a previous discovered value (pmtud). 2. Most specific route, which can be manually set when it is known that a lower MTU exists along that path. 3. Interface MTU. The third one isn't really being used because the routes inherit the MTU from the interface. Number 3 is relevant when we don't store the MTU with the route anymore unless manually set. > I believe that the quoted code above has been wrong from the day it was written, in that what it > really says is "if the route is up" and not "if the route is up and is a host route" which is > what I believe people to read that as. If the belief is that this code is really only there for > hosts routes, then the proper fix is to make the sense of the first if match that belief > and, again, to change the > to != so that when the administrator of the box bumps the MTU in > either direction that the route reflects this. It is not possible for PMTU on a single link > to a host route to bump the number down if the interface says it's not to be bumped. And, > even so, any host cache entry will override and avoid this code. The cited code is wrong in that it doesn't only test for host routes. It is correct though that it only works one way by reducing the route MTU to the interface MTU. Doing an "!=" would break manual setting of MTU on a route. IIRC this test comes from the day when we had a host route for every inpcb and changes to the interface didn't reflect back on all those host routes. It can be fixed by either testing just for (rte != NULL) or by doing away with the bogus RTF_HOST bit. Passing an inactive route to ip_output() isn't exactly useful and may lead to some later bogosity. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 19:57:01 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 117D4106564A for ; Mon, 16 Jul 2012 19:57:01 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6FC888FC12 for ; Mon, 16 Jul 2012 19:57:00 +0000 (UTC) Received: (qmail 25004 invoked from network); 16 Jul 2012 21:52:57 -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 ; 16 Jul 2012 21:52:57 -0000 Message-ID: <50047207.8060004@networx.ch> Date: Mon, 16 Jul 2012 21:56:55 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Ihsan Junaidi Ibrahim References: <3AC8C112-A80B-4D8F-89DA-DA38E4AB524F@grep.my> <0FF9D20C-4D88-484F-AEB9-E6F10094E018@grep.my> In-Reply-To: <0FF9D20C-4D88-484F-AEB9-E6F10094E018@grep.my> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Jack Vogel Subject: Re: Enable LRO by default on igb 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: Mon, 16 Jul 2012 19:57:01 -0000 On 13.07.2012 02:21, Ihsan Junaidi Ibrahim wrote: > I did a quick file download test on the LRO-enabled device (forwarding is turned on) and there's > no perceive drop-off in forwarding performance. LRO must not be active on any interface when forwarding is enabled. This has been fixed by bz@ in current and stable/9 within the LRO code and is automatic. The only remaining unhandled case is hardware-LRO where the driver must tell the hardware to stop doing it. Eventually we need an eventhandler for that and hardware-LRO cards have to register with it to get informed on changes there. -- Andre > The test is very unscientific (over the Internet) as I don't have access to a local test bed > where I can do more in-depth testing. > > Sysctl LRO stats gave me these: dev.igb.0.queue0.lro_queued: 53 dev.igb.0.queue0.lro_flushed: 53 > dev.igb.0.queue1.lro_queued: 121 dev.igb.0.queue1.lro_flushed: 120 dev.igb.0.queue2.lro_queued: > 14895 dev.igb.0.queue2.lro_flushed: 8200 dev.igb.0.queue3.lro_queued: 77 > dev.igb.0.queue3.lro_flushed: 76 > > Just curious on why flushed and queued numbers did not seem to match. > > ihsan > > On Jul 8, 2012, at 12:26 AM, Jack Vogel wrote: > >> Because of problems with forwarding when it was turned on, however this has recently been fixed >> supposedly, if someone using the driver in an environment with forwarding could verify that >> there is no problem with it enabled I'd be happy to change it to be on by default. >> >> Jack >> >> >> On Sat, Jul 7, 2012 at 9:01 AM, Ihsan Junaidi Ibrahim wrote: >> >>> Hi folks, >>> >>> Just curious is there a reason why LRO isn't turned on by default for igb(4) like for other >>> capabilities? >>> >>> I have a couple of 82575EB igb devices and LRO had to be turned on manually. >>> >>> Thanks._______________________________________________ freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to >>> "freebsd-net-unsubscribe@freebsd.org" >>> >> _______________________________________________ freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to >> "freebsd-net-unsubscribe@freebsd.org" > > _______________________________________________ freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 20:40:16 2012 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 392F910656AB for ; Mon, 16 Jul 2012 20:40:16 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A19898FC18 for ; Mon, 16 Jul 2012 20:40:15 +0000 (UTC) Received: by weyx56 with SMTP id x56so5614445wey.13 for ; Mon, 16 Jul 2012 13:40:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zL4KplPMtTkRLuLgJZuHoOlFW2dnJhdrPd9MJ0QL/F0=; b=aefOofwaipnQVoX1bEHP5K1eGJEJMChLQ6cv6683AHc1SIv4rFxds2wbItnaHkvmal z1nhb10DzAQ4GpIa6i8dqX63E2oqXNvT3q40pbqpKuJPftY6dylykBHWDvj5+EWc9AUW 5aekpmZuL+cP/Dz4EaFIOLmxfu+O7S31JExNZTXPKgOSmK0KYtjf01pnfgyhlzW6UoiI v0xDSZJY8IqYYpVI1OVOpLqVco8BNSpB+hyh6X8BK9qacwMSUhL7REloe+PIJeKgzP1y g+fElvS/v6hapeEN4tGmue/egDjw4ZHe2ttNxn3NCZyvh5iH7Bl8+V1/yfAAJRylXM0I YzqA== MIME-Version: 1.0 Received: by 10.216.74.21 with SMTP id w21mr1032898wed.77.1342471214667; Mon, 16 Jul 2012 13:40:14 -0700 (PDT) Received: by 10.180.146.130 with HTTP; Mon, 16 Jul 2012 13:40:14 -0700 (PDT) In-Reply-To: <50047207.8060004@networx.ch> References: <3AC8C112-A80B-4D8F-89DA-DA38E4AB524F@grep.my> <0FF9D20C-4D88-484F-AEB9-E6F10094E018@grep.my> <50047207.8060004@networx.ch> Date: Mon, 16 Jul 2012 13:40:14 -0700 Message-ID: From: Jack Vogel To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Ihsan Junaidi Ibrahim Subject: Re: Enable LRO by default on igb 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: Mon, 16 Jul 2012 20:40:16 -0000 Right, I was aware of the fix, so is there enough interest in this to have me get it enabled in the driver before 9.1 releases, its a couple lines of change and I'm fine with making it ?? Jack On Mon, Jul 16, 2012 at 12:56 PM, Andre Oppermann wrote: > On 13.07.2012 02:21, Ihsan Junaidi Ibrahim wrote: > >> I did a quick file download test on the LRO-enabled device (forwarding is >> turned on) and there's >> no perceive drop-off in forwarding performance. >> > > LRO must not be active on any interface when forwarding is enabled. > This has been fixed by bz@ in current and stable/9 within the LRO > code and is automatic. > > The only remaining unhandled case is hardware-LRO where the driver > must tell the hardware to stop doing it. Eventually we need an > eventhandler for that and hardware-LRO cards have to register with > it to get informed on changes there. > > -- > Andre > > > The test is very unscientific (over the Internet) as I don't have access >> to a local test bed >> where I can do more in-depth testing. >> >> Sysctl LRO stats gave me these: dev.igb.0.queue0.lro_queued: 53 >> dev.igb.0.queue0.lro_flushed: 53 >> dev.igb.0.queue1.lro_queued: 121 dev.igb.0.queue1.lro_flushed: 120 >> dev.igb.0.queue2.lro_queued: >> 14895 dev.igb.0.queue2.lro_flushed: 8200 dev.igb.0.queue3.lro_queued: 77 >> dev.igb.0.queue3.lro_flushed: 76 >> >> Just curious on why flushed and queued numbers did not seem to match. >> >> ihsan >> >> On Jul 8, 2012, at 12:26 AM, Jack Vogel wrote: >> >> Because of problems with forwarding when it was turned on, however this >>> has recently been fixed >>> supposedly, if someone using the driver in an environment with >>> forwarding could verify that >>> there is no problem with it enabled I'd be happy to change it to be on >>> by default. >>> >>> Jack >>> >>> >>> On Sat, Jul 7, 2012 at 9:01 AM, Ihsan Junaidi Ibrahim >>> wrote: >>> >>> Hi folks, >>>> >>>> Just curious is there a reason why LRO isn't turned on by default for >>>> igb(4) like for other >>>> capabilities? >>>> >>>> I have a couple of 82575EB igb devices and LRO had to be turned on >>>> manually. >>>> >>>> Thanks._______________________**________________________ >>>> freebsd-net@freebsd.org mailing list >>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-netTo unsubscribe, send any mail to >>>> "freebsd-net-unsubscribe@**freebsd.org >>>> " >>>> >>>> ______________________________**_________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/**mailman/listinfo/freebsd-netTo unsubscribe, send any mail to >>> "freebsd-net-unsubscribe@**freebsd.org >>> " >>> >> >> ______________________________**_________________ freebsd-net@freebsd.orgmailing list >> http://lists.freebsd.org/**mailman/listinfo/freebsd-netTo unsubscribe, send any mail to >> "freebsd-net-unsubscribe@**freebsd.org >> " >> >> >> > > From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 21:08:25 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 581AC106566B; Mon, 16 Jul 2012 21:08:25 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 549008FC0A; Mon, 16 Jul 2012 21:08:23 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 118B17300A; Mon, 16 Jul 2012 23:22:49 +0200 (CEST) Date: Mon, 16 Jul 2012 23:22:49 +0200 From: Luigi Rizzo To: "Alexander V. Chernikov" Message-ID: <20120716212249.GA14607@onelab2.iet.unipi.it> References: <4FF36438.2030902@FreeBSD.org> <4FF3E2C4.7050701@FreeBSD.org> <4FF3FB14.8020006@FreeBSD.org> <4FF402D1.4000505@FreeBSD.org> <20120704091241.GA99164@onelab2.iet.unipi.it> <4FF412B9.3000406@FreeBSD.org> <20120704154856.GC3680@onelab2.iet.unipi.it> <4FF59955.5090406@FreeBSD.org> <20120706061126.GA65432@onelab2.iet.unipi.it> <500452A5.3070501@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <500452A5.3070501@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Doug Barton , net@freebsd.org Subject: Re: FreeBSD 10G forwarding performance @Intel 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: Mon, 16 Jul 2012 21:08:25 -0000 On Mon, Jul 16, 2012 at 09:43:01PM +0400, Alexander V. Chernikov wrote: > On 06.07.2012 10:11, Luigi Rizzo wrote: > >On Thu, Jul 05, 2012 at 05:40:37PM +0400, Alexander V. Chernikov wrote: > >>On 04.07.2012 19:48, Luigi Rizzo wrote: > >the thing discussed a few years ago (at least the one i took out of the > >discussion) was that the counter fields in rules should hold the > >index of a per-cpu counter associated to the rule. So CTR_INC(rule->ctr) > >becomes something like pcpu->ipfw_ctrs[rule->ctr]++ > >Once you create a new rule you also grab one free index from ipfw_ctrs[], > >and the same should go for dummynet counters. > > Old kernel from previous letters, same setup: > > net.inet.ip.fw.enable=0 > 2.3 MPPS > net.inet.ip.fw.update_counters=0 > net.inet.ip.fw.enable=1 > 1.93MPPS > net.inet.ip.fw.update_counters=1 > 1.74MPPS > > Kernel with ipfw pcpu counters: > > net.inet.ip.fw.enable=0 > 2.3 MPPS > net.inet.ip.fw.update_counters=0 > net.inet.ip.fw.enable=1 > 1.93MPPS > net.inet.ip.fw.update_counters=1 > 1.93MPPS > > Counters seems to be working without any (significant) overhead. > (Maybe I'm wrong somewhere?) well, it seems that the counters are costing some 10% which is not negligible (60ns per packet according to your test). Also i'd be curious if you get better savings if you have actual conflicts on the rulesets (e.g. what happens with a ruleset that has, say, ten "count ip from any to any" rules) ? > Additionally, I've got (from my previous pcpu attempt) a small patch > permitting ipfw to re-use rule map allocation instead of reallocating > on every rule. This saves a bit of system time: > > loading 20k rules with ipfw binary gives us: > 5.1s system time before and 4.1s system time after. not bad but in this case i wonder if one wouldn't get much higher savings by support multiple rule loading with a single syscall. The format used in IPFW3 should help that. cheers luigi > > -- > WBR, Alexander > >From 931ac84b88829fe15bb4410bd2b06614f41c99b5 Mon Sep 17 00:00:00 2001 > From: "Alexander V. Chernikov" > Date: Mon, 9 Jul 2012 23:10:02 +0400 > Subject: [PATCH 1/3] Do not allocate data buffers per each rule > addition/deletion > > --- > sys/netinet/ipfw/ip_fw2.c | 2 + > sys/netinet/ipfw/ip_fw_private.h | 4 ++ > sys/netinet/ipfw/ip_fw_sockopt.c | 134 ++++++++++++++++++++++++++++++++++---- > 3 files changed, 126 insertions(+), 14 deletions(-) > > diff --git a/sys/netinet/ipfw/ip_fw2.c b/sys/netinet/ipfw/ip_fw2.c > index 98766f3..bf06c1e 100644 > --- a/sys/netinet/ipfw/ip_fw2.c > +++ b/sys/netinet/ipfw/ip_fw2.c > @@ -2701,6 +2701,8 @@ vnet_ipfw_uninit(const void *unused) > } > if (chain->map) > free(chain->map, M_IPFW); > + if (chain->b_map) > + free(chain->b_map, M_IPFW); > IPFW_WUNLOCK(chain); > IPFW_UH_WUNLOCK(chain); > if (reap != NULL) > diff --git a/sys/netinet/ipfw/ip_fw_private.h b/sys/netinet/ipfw/ip_fw_private.h > index 2806741..272cef3 100644 > --- a/sys/netinet/ipfw/ip_fw_private.h > +++ b/sys/netinet/ipfw/ip_fw_private.h > @@ -232,6 +232,10 @@ struct ip_fw_chain { > #endif > uint32_t id; /* ruleset id */ > uint32_t gencnt; /* generation count */ > + int n_allocated; /* Size of primary map in items */ > + struct ip_fw **b_map; /* Backup map to use in swapping */ > + int b_allocated; /* Size of backup map in items */ > + > }; > > struct sockopt; /* used by tcp_var.h */ > diff --git a/sys/netinet/ipfw/ip_fw_sockopt.c b/sys/netinet/ipfw/ip_fw_sockopt.c > index a245143..4e71a11 100644 > --- a/sys/netinet/ipfw/ip_fw_sockopt.c > +++ b/sys/netinet/ipfw/ip_fw_sockopt.c > @@ -97,29 +97,92 @@ ipfw_find_rule(struct ip_fw_chain *chain, uint32_t key, uint32_t id) > return hi; > } > > + > + > +/* > + * In order to minimize block allocations on every rule addition we > + * use the following technique: > + * 1) round up allocation to MAP_GRANULARITY > + * 2) Save previously allocated map to the special bakup pointer. > + * > + * This permits us do backup <> primary (and vise versa) map swapping > + * without reallocations in most cases. > + * > + */ > + > +struct map_ptrs { > + int backup; /* 1 if backup map used */ > + int items; /* number of items allocated */ > + struct ip_fw **map; > + struct ip_fw **free_map; /* map pointer to free */ > +}; > +int > +get_map(struct ip_fw_chain *chain, int extra, int locked, struct map_ptrs *ptrs); > + > +#define MAP_GRANULARITY 128 /* 1k overhead per buffer */ > +#define MAP_ROUNDUP(i) (i) + MAP_GRANULARITY - ((i) % MAP_GRANULARITY) > /* > * allocate a new map, returns the chain locked. extra is the number > * of entries to add or delete. > */ > -static struct ip_fw ** > -get_map(struct ip_fw_chain *chain, int extra, int locked) > +int > +get_map(struct ip_fw_chain *chain, int extra, int locked, struct map_ptrs *ptrs) > { > > for (;;) { > struct ip_fw **map; > int i; > > + /* Be optimistic by default */ > + if (!locked) > + IPFW_UH_WLOCK(chain); > + > i = chain->n_rules + extra; > + > + /* > + * We have to fit to the following conditions in order > + * to use backup map: > + * > + * 1) i <= chain->b_allocated (add case) > + * 2) roundup(i) == chain->b_allocated (del case) (saves memory) > + * > + * Since roundup adds 0..(MAP_GRANULARITY-1) > + * rule 2 requires rule 1 to be true. > + */ > + CTR4(KTR_NET, "%s: req: %d roundup: %d, b_allocated: %d", > + __func__, i, MAP_ROUNDUP(i), chain->b_allocated); > + > + if (MAP_ROUNDUP(i) == chain->b_allocated) { > + /* no new allocation. Just return backup map */ > + ptrs->backup = 1; > + ptrs->items = chain->b_allocated; > + ptrs->map = chain->b_map; > + CTR3(KTR_NET, "%s: BACKUP SELECTED: %p items: %d", __func__, ptrs->map, ptrs->items); > + > + return 1; > + } > + > + /* Pessimistic scenario - we need reallocation */ > + i = MAP_ROUNDUP(i); > + > + if (!locked) > + IPFW_UH_WUNLOCK(chain); > + > map = malloc(i * sizeof(struct ip_fw *), M_IPFW, > locked ? M_NOWAIT : M_WAITOK); > if (map == NULL) { > printf("%s: cannot allocate map\n", __FUNCTION__); > - return NULL; > + return 0; > } > if (!locked) > IPFW_UH_WLOCK(chain); > - if (i >= chain->n_rules + extra) /* good */ > - return map; > + if (i >= chain->n_rules + extra) { /* good */ > + ptrs->backup = 0; > + ptrs->items = i; > + ptrs->map = map; > + CTR3(KTR_NET, "%s: NEW MAP: %p items: %d", __func__, ptrs->map, ptrs->items); > + return 1; > + } > /* otherwise we lost the race, free and retry */ > if (!locked) > IPFW_UH_WUNLOCK(chain); > @@ -128,10 +191,11 @@ get_map(struct ip_fw_chain *chain, int extra, int locked) > } > > /* > - * swap the maps. It is supposed to be called with IPFW_UH_WLOCK > + * swap the maps. It is supposed to be called with IPFW_UH_WLOCK. > + * Returns old map pointer to free. > */ > static struct ip_fw ** > -swap_map(struct ip_fw_chain *chain, struct ip_fw **new_map, int new_len) > +swap_map(struct ip_fw_chain *chain, struct map_ptrs *ptrs, int new_len) > { > struct ip_fw **old_map; > > @@ -139,8 +203,43 @@ swap_map(struct ip_fw_chain *chain, struct ip_fw **new_map, int new_len) > chain->id++; > chain->n_rules = new_len; > old_map = chain->map; > - chain->map = new_map; > + chain->map = ptrs->map; > IPFW_WUNLOCK(chain); > + > + CTR4(KTR_NET, "%s: old: %p new: %p, backup: %d", > + __func__, old_map, chain->map, ptrs->backup); > + > + /* Finalize map change */ > + if (ptrs->backup) { > + /* > + * Old map has (at least) the same size as current map. > + * Save it as backup map. > + */ > + chain->b_allocated = chain->n_allocated; > + chain->n_allocated = ptrs->items; > + chain->b_map = old_map; > + ptrs->free_map = NULL; > + return old_map; > + } > + > + /* > + * Backup map is not used. Free old map and use > + * current map as candidate. > + */ > + > + /* Set free pointer to old backup map */ > + ptrs->free_map = chain->b_map; > + /* Set backup map to be old current map */ > + chain->b_map = old_map; > + > + /* Save backup map size */ > + chain->b_allocated = chain->n_allocated; > + chain->n_allocated = ptrs->items; > + > + CTR6(KTR_NET, "%s: new: %p alloc: %d backup: %p alloc: %d free: %p", > + __func__, chain->map, chain->n_allocated, > + chain->b_map, chain->b_allocated, ptrs->free_map); > + > return old_map; > } > > @@ -156,6 +255,7 @@ ipfw_add_rule(struct ip_fw_chain *chain, struct ip_fw *input_rule) > { > struct ip_fw *rule; > int i, l, insert_before; > + struct map_ptrs ptrs; > struct ip_fw **map; /* the new array of pointers */ > > if (chain->rules == NULL || input_rule->rulenum > IPFW_DEFAULT_RULE-1) > @@ -164,12 +264,13 @@ ipfw_add_rule(struct ip_fw_chain *chain, struct ip_fw *input_rule) > l = RULESIZE(input_rule); > rule = malloc(l, M_IPFW, M_WAITOK | M_ZERO); > /* get_map returns with IPFW_UH_WLOCK if successful */ > - map = get_map(chain, 1, 0 /* not locked */); > - if (map == NULL) { > + if (get_map(chain, 1, 0 /* not locked */, &ptrs) == 0) { > free(rule, M_IPFW); > return ENOSPC; > } > > + map = ptrs.map; > + > bcopy(input_rule, rule, l); > /* clear fields not settable from userland */ > rule->x_next = NULL; > @@ -201,7 +302,8 @@ ipfw_add_rule(struct ip_fw_chain *chain, struct ip_fw *input_rule) > } > > rule->id = chain->id + 1; > - map = swap_map(chain, map, chain->n_rules + 1); > + swap_map(chain, &ptrs, chain->n_rules + 1); > + map = ptrs.free_map; > chain->static_len += l; > IPFW_UH_WUNLOCK(chain); > if (map) > @@ -283,6 +385,7 @@ del_entry(struct ip_fw_chain *chain, uint32_t arg) > uint32_t num; /* rule number or old_set */ > uint8_t cmd, new_set; > int start, end, i, ofs, n; > + struct map_ptrs ptrs; > struct ip_fw **map = NULL; > int error = 0; > > @@ -353,12 +456,13 @@ del_entry(struct ip_fw_chain *chain, uint32_t arg) > } > > /* We have something to delete. Allocate the new map */ > - map = get_map(chain, -n, 1 /* locked */); > - if (map == NULL) { > + if (get_map(chain, -n, 1 /* locked */, &ptrs) == 0) { > error = EINVAL; > break; > } > > + map = ptrs.map; > + > /* 1. bcopy the initial part of the map */ > if (start > 0) > bcopy(chain->map, map, start * sizeof(struct ip_fw *)); > @@ -372,7 +476,7 @@ del_entry(struct ip_fw_chain *chain, uint32_t arg) > bcopy(chain->map + end, map + ofs, > (chain->n_rules - end) * sizeof(struct ip_fw *)); > /* 4. swap the maps (under BH_LOCK) */ > - map = swap_map(chain, map, chain->n_rules - n); > + map = swap_map(chain, &ptrs, chain->n_rules - n); > /* 5. now remove the rules deleted from the old map */ > for (i = start; i < end; i++) { > int l; > @@ -385,6 +489,8 @@ del_entry(struct ip_fw_chain *chain, uint32_t arg) > rule->x_next = chain->reap; > chain->reap = rule; > } > + /* Free map if we need to */ > + map = ptrs.free_map; > break; > > /* > -- > 1.7.9.4 > > >From baad4a88bba898baa3aa5f0dffc8a40182bcfcd6 Mon Sep 17 00:00:00 2001 > From: Charlie Root > Date: Thu, 12 Jul 2012 17:19:10 +0000 > Subject: [PATCH 1/2] Make accounting in ipfw optional > > --- > sys/netinet/ipfw/ip_fw2.c | 32 +++++++++++++++++++++----------- > 1 files changed, 21 insertions(+), 11 deletions(-) > > diff --git a/sys/netinet/ipfw/ip_fw2.c b/sys/netinet/ipfw/ip_fw2.c > index e5a13e4..7bb73b0 100644 > --- a/sys/netinet/ipfw/ip_fw2.c > +++ b/sys/netinet/ipfw/ip_fw2.c > @@ -112,6 +112,8 @@ static int default_to_accept = 1; > static int default_to_accept; > #endif > > +static int update_counters = 0; > + > VNET_DEFINE(int, autoinc_step); > > VNET_DEFINE(unsigned int, fw_tables_max); > @@ -190,6 +192,8 @@ SYSCTL_VNET_INT(_net_inet6_ip6_fw, OID_AUTO, permit_single_frag6, > "Permit single packet IPv6 fragments"); > #endif /* INET6 */ > > +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, update_counters, CTLFLAG_RW, > + &update_counters, 0, "Update counters on match"); > SYSEND > > #endif /* SYSCTL_NODE */ > @@ -2011,16 +2015,20 @@ do { \ > break; > > case O_COUNT: > - f->pcnt++; /* update stats */ > - f->bcnt += pktlen; > - f->timestamp = time_uptime; > + if (update_counters) { > + f->pcnt++; /* update stats */ > + f->bcnt += pktlen; > + f->timestamp = time_uptime; > + } > l = 0; /* exit inner loop */ > break; > > case O_SKIPTO: > - f->pcnt++; /* update stats */ > - f->bcnt += pktlen; > - f->timestamp = time_uptime; > + if (update_counters) { > + f->pcnt++; /* update stats */ > + f->bcnt += pktlen; > + f->timestamp = time_uptime; > + } > /* If possible use cached f_pos (in f->next_rule), > * whose version is written in f->next_rule > * (horrible hacks to avoid changing the ABI). > @@ -2375,11 +2383,13 @@ do { \ > } /* end of outer for, scan rules */ > > if (done) { > - struct ip_fw *rule = chain->map[f_pos]; > - /* Update statistics */ > - rule->pcnt++; > - rule->bcnt += pktlen; > - rule->timestamp = time_uptime; > + if (update_counters) { > + struct ip_fw *rule = chain->map[f_pos]; > + /* Update statistics */ > + rule->pcnt++; > + rule->bcnt += pktlen; > + rule->timestamp = time_uptime; > + } > } else { > retval = IP_FW_DENY; > printf("ipfw: ouch!, skip past end of rules, denying packet\n"); > -- > 1.7.6.1 > > diff --git a/sys/netinet/ip_fw.h b/sys/netinet/ip_fw.h > index 589c19c..b1f83bb 100644 > --- a/sys/netinet/ip_fw.h > +++ b/sys/netinet/ip_fw.h > @@ -493,9 +493,14 @@ struct ip_fw { > uint32_t id; /* rule id */ > > /* These fields are present in all rules. */ > +#if 0 > uint64_t pcnt; /* Packet counter */ > uint64_t bcnt; /* Byte counter */ > uint32_t timestamp; /* tv_sec of last match */ > +#endif > + uint64_t _pad0; > + uint64_t _pad1; > + uint32_t cntr_idx; /* Index in pcpu counters */ > > ipfw_insn cmd[1]; /* storage for commands */ > }; > diff --git a/sys/netinet/ipfw/ip_fw2.c b/sys/netinet/ipfw/ip_fw2.c > index 7bb73b0..db93a5c 100644 > --- a/sys/netinet/ipfw/ip_fw2.c > +++ b/sys/netinet/ipfw/ip_fw2.c > @@ -2016,18 +2016,20 @@ do { \ > > case O_COUNT: > if (update_counters) { > - f->pcnt++; /* update stats */ > - f->bcnt += pktlen; > - f->timestamp = time_uptime; > + struct ip_fw_cntr *c = IPFW_PCPU_CNTR(chain, f->cntr_idx); > + c->pcnt++; /* update stats */ > + c->bcnt += pktlen; > + c->timestamp = time_uptime; > } > l = 0; /* exit inner loop */ > break; > > case O_SKIPTO: > if (update_counters) { > - f->pcnt++; /* update stats */ > - f->bcnt += pktlen; > - f->timestamp = time_uptime; > + struct ip_fw_cntr *c = IPFW_PCPU_CNTR(chain, f->cntr_idx); > + c->pcnt++; /* update stats */ > + c->bcnt += pktlen; > + c->timestamp = time_uptime; > } > /* If possible use cached f_pos (in f->next_rule), > * whose version is written in f->next_rule > @@ -2125,9 +2127,10 @@ do { \ > break; > } > > - f->pcnt++; /* update stats */ > - f->bcnt += pktlen; > - f->timestamp = time_uptime; > + struct ip_fw_cntr *c = IPFW_PCPU_CNTR(chain, f->cntr_idx); > + c->pcnt++; /* update stats */ > + c->bcnt += pktlen; > + c->timestamp = time_uptime; > stack = (uint16_t *)(mtag + 1); > > /* > @@ -2263,9 +2266,10 @@ do { \ > case O_SETFIB: { > uint32_t fib; > > - f->pcnt++; /* update stats */ > - f->bcnt += pktlen; > - f->timestamp = time_uptime; > + struct ip_fw_cntr *c = IPFW_PCPU_CNTR(chain, f->cntr_idx); > + c->pcnt++; /* update stats */ > + c->bcnt += pktlen; > + c->timestamp = time_uptime; > fib = (cmd->arg1 == IP_FW_TABLEARG) ? tablearg: > cmd->arg1; > if (fib >= rt_numfibs) > @@ -2315,8 +2319,9 @@ do { \ > case O_REASS: { > int ip_off; > > - f->pcnt++; > - f->bcnt += pktlen; > + struct ip_fw_cntr *c = IPFW_PCPU_CNTR(chain, f->cntr_idx); > + c->pcnt++; > + c->bcnt += pktlen; > l = 0; /* in any case exit inner loop */ > ip_off = ntohs(ip->ip_off); > > @@ -2386,9 +2391,10 @@ do { \ > if (update_counters) { > struct ip_fw *rule = chain->map[f_pos]; > /* Update statistics */ > - rule->pcnt++; > - rule->bcnt += pktlen; > - rule->timestamp = time_uptime; > + struct ip_fw_cntr *c = IPFW_PCPU_CNTR(chain, rule->cntr_idx); > + c->pcnt++; > + c->bcnt += pktlen; > + c->timestamp = time_uptime; > } > } else { > retval = IP_FW_DENY; > @@ -2439,6 +2445,7 @@ ipfw_init(void) > { > int error = 0; > > + _dpcpu_init(); > ipfw_dyn_attach(); > /* > * Only print out this stuff the first time around, > @@ -2500,6 +2507,7 @@ ipfw_destroy(void) > > ipfw_log_bpf(0); /* uninit */ > ipfw_dyn_detach(); > + _dpcpu_uninit(); > printf("IP firewall unloaded\n"); > } > > @@ -2546,6 +2554,9 @@ vnet_ipfw_init(const void *unused) > return (ENOSPC); > } > > + /* Init per-cpu counters */ > + ipfw_init_counters(chain); > + > /* fill and insert the default rule */ > rule->act_ofs = 0; > rule->rulenum = IPFW_DEFAULT_RULE; > @@ -2559,6 +2570,9 @@ vnet_ipfw_init(const void *unused) > IPFW_LOCK_INIT(chain); > ipfw_dyn_init(); > > + /* Allocate first pcpu counter */ > + rule->cntr_idx = ipfw_alloc_counter(chain); > + > /* First set up some values that are compile time options */ > V_ipfw_vnet_ready = 1; /* Open for business */ > > @@ -2619,10 +2633,11 @@ vnet_ipfw_uninit(const void *unused) > } > if (chain->map) > free(chain->map, M_IPFW); > + _dpcpu_free(chain->cntrs); > IPFW_WUNLOCK(chain); > IPFW_UH_WUNLOCK(chain); > if (reap != NULL) > - ipfw_reap_rules(reap); > + ipfw_reap_rules(chain, reap); > IPFW_LOCK_DESTROY(chain); > ipfw_dyn_uninit(1); /* free the remaining parts */ > return 0; > diff --git a/sys/netinet/ipfw/ip_fw_private.h b/sys/netinet/ipfw/ip_fw_private.h > index 46d011c..bd4fad3 100644 > --- a/sys/netinet/ipfw/ip_fw_private.h > +++ b/sys/netinet/ipfw/ip_fw_private.h > @@ -222,6 +222,7 @@ struct ip_fw_chain { > struct radix_node_head **tables; /* IPv4 tables */ > struct radix_node_head **xtables; /* extended tables */ > uint8_t *tabletype; /* Array of table types */ > + uintptr_t *cntrs; /* Per-cpu counters */ > #if defined( __linux__ ) || defined( _WIN32 ) > spinlock_t rwmtx; > spinlock_t uh_lock; > @@ -231,8 +232,25 @@ struct ip_fw_chain { > #endif > uint32_t id; /* ruleset id */ > uint32_t gencnt; /* generation count */ > + int cntr_allocated; /* Size of allocated counters map */ > + uint32_t *cntr_idx; /* bit index of counters map */ > }; > > +struct ip_fw_cntr { > + uint64_t pcnt; /* Packet counter */ > + uint64_t bcnt; /* Byte counter */ > + uint32_t timestamp; /* tv_sec of last match */ > +}; > +#define IPFW_PCPU_CNTR(chain, idx) ((struct ip_fw_cntr *)(chain)->cntrs[curcpu] + idx) > +#define IPFW_PCPU_DEFAULT_COUNTERS 128 > +void _dpcpu_init(void); > +void _dpcpu_uninit(void); > +uintptr_t *_dpcpu_alloc(size_t size, int flags); > +void _dpcpu_free(uintptr_t *ptr); > +void ipfw_init_counters(struct ip_fw_chain *chain); > +int ipfw_alloc_counter(struct ip_fw_chain *chain); > +void ipfw_free_counter(struct ip_fw_chain *chain, int idx); > + > struct sockopt; /* used by tcp_var.h */ > > /* > @@ -267,7 +285,10 @@ int ipfw_find_rule(struct ip_fw_chain *chain, uint32_t key, uint32_t id); > int ipfw_add_rule(struct ip_fw_chain *chain, struct ip_fw *input_rule); > int ipfw_ctl(struct sockopt *sopt); > int ipfw_chk(struct ip_fw_args *args); > -void ipfw_reap_rules(struct ip_fw *head); > +void ipfw_reap_rules(struct ip_fw_chain *chain, struct ip_fw *head); > + > +void ipfw_zero_counter(struct ip_fw_chain *chain, int idx); > +void ipfw_export_counter(struct ip_fw_chain *chain, int idx, struct ip_fw_cntr *cntr); > > /* In ip_fw_pfil */ > int ipfw_check_hook(void *arg, struct mbuf **m0, struct ifnet *ifp, int dir, > diff --git a/sys/netinet/ipfw/ip_fw_sockopt.c b/sys/netinet/ipfw/ip_fw_sockopt.c > index 0aecc2c..db308c2 100644 > --- a/sys/netinet/ipfw/ip_fw_sockopt.c > +++ b/sys/netinet/ipfw/ip_fw_sockopt.c > @@ -45,6 +45,7 @@ __FBSDID("$FreeBSD$"); > #include > #include /* struct m_tag used by nested headers */ > #include > +#include > #include > #include > #include > @@ -72,6 +73,212 @@ MALLOC_DEFINE(M_IPFW, "IpFw/IpAcct", "IpFw/IpAcct chain's"); > * static variables followed by global ones (none in this file) > */ > > +MALLOC_DEFINE(M_XDPCPU, "XPCPU", "PCPU data"); > + > +uma_zone_t _dpcpu_zone; > + > +static void ipfw_extend_counters(struct ip_fw_chain *chain); > + > +void > +_dpcpu_init() > +{ > + _dpcpu_zone = uma_zcreate("pcpu ptrs", sizeof(uintptr_t) * MAXCPU, > + NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, 0); > +} > + > +void > +_dpcpu_uninit() > +{ > + uma_zdestroy(_dpcpu_zone); > +} > + > +#define _DPCPU_ALIGN 512 > +uintptr_t * > +_dpcpu_alloc(size_t size, int flags) > +{ > + uintptr_t *ptr; > + int id, fail = 0; > + > + if (size % _DPCPU_ALIGN) > + size += _DPCPU_ALIGN - (size % _DPCPU_ALIGN); > + > + if ((ptr = uma_zalloc(_dpcpu_zone, flags | M_ZERO)) == NULL) > + return NULL; > + > + CPU_FOREACH(id) { > + /* > + * We believe in aligned allocation here > + */ > + if ((ptr[id] = (uintptr_t)malloc(size, M_XDPCPU, flags)) == 0) { > + fail = 1; > + break; > + } > + > + KASSERT((uintptr_t)ptr % _DPCPU_ALIGN == 0, ("malloc(9) returns unaligned data :(")); > + } > + > + if (fail == 0) > + return ptr; > + > + CPU_FOREACH(id) { > + if (ptr[id] == 0) > + break; > + > + free((void *)ptr[id], M_XDPCPU); > + } > + > + uma_zfree(_dpcpu_zone, ptr); > + > + return NULL; > +} > + > +void > +_dpcpu_free(uintptr_t *ptr) > +{ > + int id; > + > + CPU_FOREACH(id) { > + if (ptr[id] == 0) > + continue; > + free((void *)ptr[id], M_XDPCPU); > + } > + > + uma_zfree(_dpcpu_zone, ptr); > +} > + > +void > +ipfw_init_counters(struct ip_fw_chain *chain) > +{ > + chain->cntrs = _dpcpu_alloc(IPFW_PCPU_DEFAULT_COUNTERS * > + sizeof(struct ip_fw_cntr), M_WAITOK | M_ZERO); > + chain->cntr_idx = malloc(IPFW_PCPU_DEFAULT_COUNTERS / 8, M_IPFW, M_WAITOK); > + /* Free positions are marked by 1 */ > + memset(chain->cntr_idx, 0xFF, IPFW_PCPU_DEFAULT_COUNTERS / 8); > + chain->cntr_allocated = IPFW_PCPU_DEFAULT_COUNTERS; > +} > + > + > +static void > +ipfw_extend_counters(struct ip_fw_chain *chain) > +{ > + uintptr_t *new_ptr, *old_ptr; > + uint32_t *old_idx, *new_idx; > + int i, id; > + > + for (;;) { > + > + i = 2 * chain->cntr_allocated; > + > + new_ptr = _dpcpu_alloc(i * sizeof(struct ip_fw_cntr), M_WAITOK | M_ZERO); > + new_idx = malloc(i / 8, M_IPFW, M_WAITOK); > + /* Free positions are marked by 1 */ > + memset(new_idx, 0xFF, i / 8); > + > + IPFW_UH_WLOCK(chain); > + if (i == 2 * chain->cntr_allocated) { > + CTR4(KTR_NET, "%s: NEW INDEX: %p cntr_idx: %d count: %d", __func__, new_ptr, new_idx, i); > + break; > + } > + /* otherwise we lost the race, free and retry */ > + IPFW_UH_WUNLOCK(chain); > + > + free(new_idx, M_IPFW); > + _dpcpu_free(new_ptr); > + } > + > + /* Pointers allocated, let's migrate data */ > + > + IPFW_WLOCK(chain); > + /* Copy pcpu counters */ > + CPU_FOREACH(id) { > + memcpy((void *)new_ptr[id], (void *)chain->cntrs[id], chain->cntr_allocated * sizeof(struct ip_fw_cntr)); > + } > + /* Copy index */ > + memcpy(new_idx, chain->cntr_idx, chain->cntr_allocated / 8); > + /* Swap old and new pointers */ > + old_ptr = chain->cntrs; > + chain->cntrs = new_ptr; > + old_idx = chain->cntr_idx; > + chain->cntr_idx = new_idx; > + chain->cntr_allocated = i; > + > + IPFW_WUNLOCK(chain); > + IPFW_UH_WUNLOCK(chain); > + > + /* Free old counters and index */ > + free(old_idx, M_IPFW); > + _dpcpu_free(old_ptr); > +} > + > +int > +ipfw_alloc_counter(struct ip_fw_chain *chain) > +{ > + int i, x, idx; > + uint32_t *v; > + > + for (;;) { > + IPFW_UH_WLOCK(chain); > + for (i = 0, v = chain->cntr_idx; i < chain->cntr_allocated / 8 / 4; i++, v++) { > + if ((x = ffsl(*v)) != 0) { > + /* Found. Mark as used */ > + *v &= ~ (1 << (x - 1)); > + IPFW_UH_WUNLOCK(chain); > + idx = i * 32 + x - 1; > + ipfw_zero_counter(chain, idx); > + CTR3(KTR_NET, "%s: allocated counter %d, map after: %X", __func__, idx, *v); > + return idx; > + } > + } > + IPFW_UH_WUNLOCK(chain); > + > + /* Not found. Let's allocate data and retry */ > + ipfw_extend_counters(chain); > + } > +} > + > +void > +ipfw_free_counter(struct ip_fw_chain *chain, int idx) > +{ > + uint32_t *v; > + > + IPFW_UH_WLOCK(chain); > + v = chain->cntr_idx; > + v += idx / 32; > + CTR3(KTR_NET, "%s: returned counter %d, map before: %X", __func__, idx, *v); > + idx %= 32; > + *v |= 1 << idx; > + > + IPFW_UH_WUNLOCK(chain); > +} > + > +void > +ipfw_zero_counter(struct ip_fw_chain *chain, int idx) > +{ > + int id; > + struct ip_fw_cntr *pcpu; > + > + CTR2(KTR_NET, "%s: zeroing counter %d", __func__, idx); > + CPU_FOREACH(id) { > + pcpu = ((struct ip_fw_cntr *)chain->cntrs[id]) + idx; > + memset(pcpu, 0, sizeof(struct ip_fw_cntr)); > + } > +} > + > +void > +ipfw_export_counter(struct ip_fw_chain *chain, int idx, struct ip_fw_cntr *cntr) > +{ > + int id; > + struct ip_fw_cntr *pcpu; > + > + CPU_FOREACH(id) { > + pcpu = ((struct ip_fw_cntr *)chain->cntrs[id]) + idx; > + cntr->pcnt += pcpu->pcnt; > + cntr->bcnt += pcpu->bcnt; > + if (cntr->timestamp < pcpu->timestamp) > + cntr->timestamp = pcpu->timestamp; > + } > +} > + > /* > * Find the smallest rule >= key, id. > * We could use bsearch but it is so simple that we code it directly > @@ -155,7 +362,7 @@ int > ipfw_add_rule(struct ip_fw_chain *chain, struct ip_fw *input_rule) > { > struct ip_fw *rule; > - int i, l, insert_before; > + int i, l, cntr_idx, insert_before; > struct ip_fw **map; /* the new array of pointers */ > > if (chain->rules == NULL || input_rule->rulenum > IPFW_DEFAULT_RULE-1) > @@ -163,12 +370,14 @@ ipfw_add_rule(struct ip_fw_chain *chain, struct ip_fw *input_rule) > > l = RULESIZE(input_rule); > rule = malloc(l, M_IPFW, M_WAITOK | M_ZERO); > + cntr_idx = ipfw_alloc_counter(chain); > if (rule == NULL) > return (ENOSPC); > /* get_map returns with IPFW_UH_WLOCK if successful */ > map = get_map(chain, 1, 0 /* not locked */); > if (map == NULL) { > free(rule, M_IPFW); > + ipfw_free_counter(chain, cntr_idx); > return ENOSPC; > } > > @@ -176,10 +385,12 @@ ipfw_add_rule(struct ip_fw_chain *chain, struct ip_fw *input_rule) > /* clear fields not settable from userland */ > rule->x_next = NULL; > rule->next_rule = NULL; > + rule->cntr_idx = cntr_idx; > +#if 0 > rule->pcnt = 0; > rule->bcnt = 0; > rule->timestamp = 0; > - > +#endif > if (V_autoinc_step < 1) > V_autoinc_step = 1; > else if (V_autoinc_step > 1000) > @@ -217,12 +428,13 @@ ipfw_add_rule(struct ip_fw_chain *chain, struct ip_fw *input_rule) > * A NULL pointer on input is handled correctly. > */ > void > -ipfw_reap_rules(struct ip_fw *head) > +ipfw_reap_rules(struct ip_fw_chain *chain, struct ip_fw *head) > { > struct ip_fw *rule; > > while ((rule = head) != NULL) { > head = head->x_next; > + ipfw_free_counter(chain, rule->cntr_idx); > free(rule, M_IPFW); > } > } > @@ -424,7 +636,7 @@ del_entry(struct ip_fw_chain *chain, uint32_t arg) > rule = chain->reap; > chain->reap = NULL; > IPFW_UH_WUNLOCK(chain); > - ipfw_reap_rules(rule); > + ipfw_reap_rules(chain, rule); > if (map) > free(map, M_IPFW); > return error; > @@ -436,13 +648,17 @@ del_entry(struct ip_fw_chain *chain, uint32_t arg) > * so we only care that rules do not disappear. > */ > static void > -clear_counters(struct ip_fw *rule, int log_only) > +clear_counters(struct ip_fw_chain *chain, struct ip_fw *rule, int log_only) > { > ipfw_insn_log *l = (ipfw_insn_log *)ACTION_PTR(rule); > > if (log_only == 0) { > +#if 0 > rule->bcnt = rule->pcnt = 0; > rule->timestamp = 0; > +#endif > + ipfw_zero_counter(chain, rule->cntr_idx); > + > } > if (l->o.opcode == O_LOG) > l->log_left = l->max_log; > @@ -481,7 +697,7 @@ zero_entry(struct ip_fw_chain *chain, u_int32_t arg, int log_only) > /* Skip rules not in our set. */ > if (cmd == 1 && rule->set != set) > continue; > - clear_counters(rule, log_only); > + clear_counters(chain, rule, log_only); > } > msg = log_only ? "All logging counts reset" : > "Accounting cleared"; > @@ -491,7 +707,7 @@ zero_entry(struct ip_fw_chain *chain, u_int32_t arg, int log_only) > rule = chain->map[i]; > if (rule->rulenum == rulenum) { > if (cmd == 0 || rule->set == set) > - clear_counters(rule, log_only); > + clear_counters(chain, rule, log_only); > cleared = 1; > } > if (rule->rulenum > rulenum) > @@ -854,7 +1070,7 @@ struct ip_fw7 { > ipfw_insn cmd[1]; /* storage for commands */ > }; > > - int convert_rule_to_7(struct ip_fw *rule); > +int convert_rule_to_7(struct ip_fw_chain *chain, struct ip_fw *rule); > int convert_rule_to_8(struct ip_fw *rule); > > #ifndef RULESIZE7 > @@ -887,7 +1103,7 @@ ipfw_getrules(struct ip_fw_chain *chain, void *buf, size_t space) > if (bp + l + sizeof(uint32_t) <= ep) { > int error; > bcopy(rule, bp, l + sizeof(uint32_t)); > - error = convert_rule_to_7((struct ip_fw *) bp); > + error = convert_rule_to_7(chain, (struct ip_fw *) bp); > if (error) > return 0; /*XXX correct? */ > /* > @@ -913,14 +1129,19 @@ ipfw_getrules(struct ip_fw_chain *chain, void *buf, size_t space) > } > dst = (struct ip_fw *)bp; > bcopy(rule, dst, l); > + /* copy statistics */ > + struct ip_fw_cntr *c = (struct ip_fw_cntr *)&dst->_pad0; > + ipfw_export_counter(chain, rule->cntr_idx, c); > + if (c->timestamp) > + c->timestamp += boot_seconds; > + > /* > * XXX HACK. Store the disable mask in the "next" > * pointer in a wild attempt to keep the ABI the same. > * Why do we do this on EVERY rule? > */ > bcopy(&V_set_disable, &dst->next_rule, sizeof(V_set_disable)); > - if (dst->timestamp) > - dst->timestamp += boot_seconds; > + > bp += l; > } > ipfw_get_dynamic(&bp, ep); /* protected by the dynamic lock */ > @@ -1051,7 +1272,7 @@ ipfw_ctl(struct sockopt *sopt) > size = RULESIZE(rule); > if (!error && sopt->sopt_dir == SOPT_GET) { > if (is7) { > - error = convert_rule_to_7(rule); > + error = convert_rule_to_7(chain, rule); > size = RULESIZE7(rule); > if (error) > return error; > @@ -1329,7 +1550,7 @@ ipfw_ctl(struct sockopt *sopt) > > /* Functions to convert rules 7.2 <==> 8.0 */ > int > -convert_rule_to_7(struct ip_fw *rule) > +convert_rule_to_7(struct ip_fw_chain *chain, struct ip_fw *rule) > { > /* Used to modify original rule */ > struct ip_fw7 *rule7 = (struct ip_fw7 *)rule; > @@ -1355,9 +1576,12 @@ convert_rule_to_7(struct ip_fw *rule) > rule7->next_rule = (struct ip_fw7 *)tmp->next_rule; > rule7->next = (struct ip_fw7 *)tmp->x_next; > rule7->cmd_len = tmp->cmd_len; > + ipfw_export_counter(chain, rule->cntr_idx, (struct ip_fw_cntr *)&rule7->pcnt); > +#if 0 > rule7->pcnt = tmp->pcnt; > rule7->bcnt = tmp->bcnt; > rule7->timestamp = tmp->timestamp; > +#endif > > /* Copy commands */ > for (ll = tmp->cmd_len, ccmd = tmp->cmd, dst = rule7->cmd ; > @@ -1429,10 +1653,11 @@ convert_rule_to_8(struct ip_fw *rule) > rule->x_next = (struct ip_fw *)tmp->next; > rule->cmd_len = tmp->cmd_len; > rule->id = 0; /* XXX see if is ok = 0 */ > +#if 0 > rule->pcnt = tmp->pcnt; > rule->bcnt = tmp->bcnt; > rule->timestamp = tmp->timestamp; > - > +#endif > free (tmp, M_TEMP); > return 0; > } From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 21:40:08 2012 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 5A868106566B for ; Mon, 16 Jul 2012 21:40:08 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id C5EB68FC0A for ; Mon, 16 Jul 2012 21:40:07 +0000 (UTC) Received: by lbon10 with SMTP id n10so10024623lbo.13 for ; Mon, 16 Jul 2012 14:40:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=Hh0RWTB5ERfY8sOpjT5+ZiU86PoJF4RCz6Q7Nsew2ww=; b=hW0KS9LtZ2Aftjs5gYR+Jw8QyiZOAHZNtFksNW/8MboEQI+BhqxNsclMfxlPKTDNNB SglqKnp68QKEqeX5saMO/adHVexB9WwKvErlLx9oqkpz7w+G87EB97SlQjVodQs52Lry VSbvfyP6KxmSiGajFE65aIQ79I++BWlwNrFQh7ZDKzLqOuvog3XmLXaSaJHc/fs3gjl6 MSckw6zdS7Fynw4y2GzeF9r/A6438rAVZKtlSOfPlWzVIobVfbfdyrfXNtR6FZONi1BQ lvzSg2MVcNWDHSJzyoSEC1Is9xue499R5Shi+jGCWWK1DcBI287nvpQL5EoBarrz8WXP FmVg== Received: by 10.152.105.173 with SMTP id gn13mr3821926lab.20.1342474806773; Mon, 16 Jul 2012 14:40:06 -0700 (PDT) Received: from zont-osx.local (ppp95-165-138-37.pppoe.spdop.ru. [95.165.138.37]) by mx.google.com with ESMTPS id er3sm3731032lbb.16.2012.07.16.14.40.05 (version=SSLv3 cipher=OTHER); Mon, 16 Jul 2012 14:40:06 -0700 (PDT) Message-ID: <50048A34.10304@zonov.org> Date: Tue, 17 Jul 2012 01:40:04 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" References: <5003EDC4.3050100@zonov.org> In-Reply-To: <5003EDC4.3050100@zonov.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmJKYZktsI1eEjbKl/nMzoTTbn6dafm6vGavFianQUdPbnBsiW7XKX0D3Paxcq2vQIlhErW Subject: Re: panic: negative refcount 0xfffffe0007f1b4d4 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: Mon, 16 Jul 2012 21:40:08 -0000 On 7/16/12 2:32 PM, Andrey Zonov wrote: > Hi, > > I've got about 30 machines which panic sometimes in different places but > with the same panic message: "negative refcount 0xfffffe0007f1b4d4". > They are running under 9.0-STABLE@r234600M. > [snip] > > Is this known issue? If it is not, I've got textdumps and can send to > anyone who wants to help me. > > Thanks in advance. > So, this is the one more ifa leak. # kgdb define print_ip set $_cp = (unsigned char *)$arg0 printf "%d.%d.%d.%d", $_cp[0], $_cp[1], $_cp[2], $_cp[3] end define print_sin set $_ip = &((struct sockaddr_in *)$arg0)->sin_addr print_ip $_ip end define refcnt set $ifp = ((struct ifnethead *) (vnet0->vnet_data_base + (long)&vnet_entry_ifnet)).tqh_first while ($ifp != 0) set $ifa = $ifp->if_addrhead.tqh_first while ($ifa != 0) if ($ifa->ifa_addr->sa_family == 2) printf "%s: inet", $ifp->if_xname print_sin $ifa->ifa_addr printf "\tcnt: %u \n", $ifa->ifa_refcnt end set $ifa = $ifa->ifa_link.tqe_next end set $ifp = $ifp->if_link.tqe_next end end (kgdb) refcnt em0: inet 77.88.6.34 cnt: 2746302764 lo0: inet 127.0.0.1 cnt: 28 (kgdb) refcnt em0: inet 77.88.6.34 cnt: 2746321183 lo0: inet 127.0.0.1 cnt: 28 (kgdb) refcnt em0: inet 77.88.6.34 cnt: 2746539500 lo0: inet 127.0.0.1 cnt: 28 Is there a method to detect such leaks? -- Andrey Zonov From owner-freebsd-net@FreeBSD.ORG Mon Jul 16 23:23:56 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC060106566B; Mon, 16 Jul 2012 23:23:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 4DD228FC08; Mon, 16 Jul 2012 23:23:56 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6GNO5cF093778; Tue, 17 Jul 2012 02:24:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q6GNNqVh074202; Tue, 17 Jul 2012 02:23:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6GNNqYS074201; Tue, 17 Jul 2012 02:23:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 17 Jul 2012 02:23:52 +0300 From: Konstantin Belousov To: "Alexander V. Chernikov" Message-ID: <20120716232352.GE2676@deviant.kiev.zoral.com.ua> References: <4FF36438.2030902@FreeBSD.org> <4FF3E2C4.7050701@FreeBSD.org> <4FF3FB14.8020006@FreeBSD.org> <4FF402D1.4000505@FreeBSD.org> <20120704091241.GA99164@onelab2.iet.unipi.it> <4FF412B9.3000406@FreeBSD.org> <20120704154856.GC3680@onelab2.iet.unipi.it> <4FF59955.5090406@FreeBSD.org> <20120706061126.GA65432@onelab2.iet.unipi.it> <500452A5.3070501@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d8Lz2Tf5e5STOWUP" Content-Disposition: inline In-Reply-To: <500452A5.3070501@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Doug Barton , Luigi Rizzo , net@freebsd.org Subject: Re: FreeBSD 10G forwarding performance @Intel 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: Mon, 16 Jul 2012 23:23:57 -0000 --d8Lz2Tf5e5STOWUP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 16, 2012 at 09:43:01PM +0400, Alexander V. Chernikov wrote: > On 06.07.2012 10:11, Luigi Rizzo wrote: > >On Thu, Jul 05, 2012 at 05:40:37PM +0400, Alexander V. Chernikov wrote: > >>On 04.07.2012 19:48, Luigi Rizzo wrote: > >the thing discussed a few years ago (at least the one i took out of the > >discussion) was that the counter fields in rules should hold the > >index of a per-cpu counter associated to the rule. So CTR_INC(rule->ctr) > >becomes something like pcpu->ipfw_ctrs[rule->ctr]++ > >Once you create a new rule you also grab one free index from ipfw_ctrs[], > >and the same should go for dummynet counters. >=20 > Old kernel from previous letters, same setup: >=20 > net.inet.ip.fw.enable=3D0 > 2.3 MPPS > net.inet.ip.fw.update_counters=3D0 > net.inet.ip.fw.enable=3D1 > 1.93MPPS > net.inet.ip.fw.update_counters=3D1 > 1.74MPPS >=20 > Kernel with ipfw pcpu counters: >=20 > net.inet.ip.fw.enable=3D0 > 2.3 MPPS > net.inet.ip.fw.update_counters=3D0 > net.inet.ip.fw.enable=3D1 > 1.93MPPS > net.inet.ip.fw.update_counters=3D1 > 1.93MPPS >=20 > Counters seems to be working without any (significant) overhead. > (Maybe I'm wrong somewhere?) >=20 > Additionally, I've got (from my previous pcpu attempt) a small patch=20 > permitting ipfw to re-use rule map allocation instead of reallocating=20 > on every rule. This saves a bit of system time: >=20 > loading 20k rules with ipfw binary gives us: > 5.1s system time before and 4.1s system time after. >=20 I do not think that your 'per-cpu' counter are correct. The thread migration or rescheduling causes the fetch or update of the wrong per-cpu structure. This allows parallel updates with undefined consequences. As a lowest thing to do, you need to disable preeemption around counter structure dereference and increment. --d8Lz2Tf5e5STOWUP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAEoogACgkQC3+MBN1Mb4j+WACfR/QhjNQeVUa/byYwoHT3lsHv WaMAnAkOPkpds/lMkJbshJVTZXn05Op6 =7n6q -----END PGP SIGNATURE----- --d8Lz2Tf5e5STOWUP-- From owner-freebsd-net@FreeBSD.ORG Tue Jul 17 07:17:44 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 548CA106564A; Tue, 17 Jul 2012 07:17:44 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5D6A98FC17; Tue, 17 Jul 2012 07:17:43 +0000 (UTC) Received: by lbon10 with SMTP id n10so302070lbo.13 for ; Tue, 17 Jul 2012 00:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=4ZLnsMuDa4ji3ZLvCnJy0Yxo9gGFZrdcPXvvF/8vgC4=; b=H5HpjOIJ1rOXx0rsvvgMocZ230WKvOudVXAQKgV2k3teV1DE+oFggvWHorNYydZRp0 Fgcgf6oFY5E3vMiCnsOMybZQBw7Lmx3Gk1yjE65knBZdK+ncQV0/XQZALDY5Gok6cRcH /mnwfe3rGC2GaQ40cekUdpjgmg5/YFfV1+cfWHEBzTGHpywkDjwirGI4JWyFt3ogwyvr LFgP1eFgg6wOUQA1j2pH8U9/p9EdjVbGeQn0rCb0u2uI1Jm6qAlp2MmI4tJW4OytGWEx k81bH5Ny4QsNBs9Y9XMtnpZZCUrWZwKvhqqGDq4qA3awQ1u+9SdCPDewixcj9lilEVSC yFwQ== Received: by 10.152.148.169 with SMTP id tt9mr1296928lab.49.1342509462131; Tue, 17 Jul 2012 00:17:42 -0700 (PDT) Received: from [127.0.0.1] ([84.241.57.181]) by mx.google.com with ESMTPS id p2sm3929294lbj.4.2012.07.17.00.17.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Jul 2012 00:17:40 -0700 (PDT) Message-ID: <500511A6.9010808@gmail.com> Date: Tue, 17 Jul 2012 11:47:58 +0430 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: "Alexander V. Chernikov" References: <4FF361CA.4000506@FreeBSD.org> <20120703214419.GC92445@onelab2.iet.unipi.it> <4FF36438.2030902@FreeBSD.org> <4FF3E2C4.7050701@FreeBSD.org> <4FF3FB14.8020006@FreeBSD.org> <4FF402D1.4000505@FreeBSD.org> <20120704091241.GA99164@onelab2.iet.unipi.it> <4FF412B9.3000406@FreeBSD.org> <20120704154856.GC3680@onelab2.iet.unipi.it> <4FF59955.5090406@FreeBSD.org> <20120706061126.GA65432@onelab2.iet.unipi.it> <500452A5.3070501@FreeBSD.org> In-Reply-To: <500452A5.3070501@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Doug Barton , Luigi Rizzo , net@freebsd.org Subject: Re: FreeBSD 10G forwarding performance @Intel 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, 17 Jul 2012 07:17:44 -0000 On 7/16/2012 10:13 PM, Alexander V. Chernikov wrote: > Old kernel from previous letters, same setup: > > net.inet.ip.fw.enable=0 > 2.3 MPPS > net.inet.ip.fw.update_counters=0 > net.inet.ip.fw.enable=1 > 1.93MPPS > net.inet.ip.fw.update_counters=1 > 1.74MPPS > > Kernel with ipfw pcpu counters: > > net.inet.ip.fw.enable=0 > 2.3 MPPS > net.inet.ip.fw.update_counters=0 > net.inet.ip.fw.enable=1 > 1.93MPPS > net.inet.ip.fw.update_counters=1 > 1.93MPPS > > Counters seems to be working without any (significant) overhead. > (Maybe I'm wrong somewhere?) > > Additionally, I've got (from my previous pcpu attempt) a small patch permitting ipfw to re-use rule map allocation instead of reallocating on every rule. This saves a bit of system time: > > loading 20k rules with ipfw binary gives us: > 5.1s system time before and 4.1s system time after. > > May be slightly off-topic, but do you have tested (or have plans to test ) with bidirectional traffic? From owner-freebsd-net@FreeBSD.ORG Tue Jul 17 07:32:40 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 3556D106564A; Tue, 17 Jul 2012 07:32:40 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from dhcp170-36-red.yandex.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with ESMTP id 0DDA8152273; Tue, 17 Jul 2012 07:32:37 +0000 (UTC) Message-ID: <500514AB.2090701@FreeBSD.org> Date: Tue, 17 Jul 2012 11:30:51 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120511 Thunderbird/12.0.1 MIME-Version: 1.0 To: Hooman Fazaeli References: <4FF361CA.4000506@FreeBSD.org> <20120703214419.GC92445@onelab2.iet.unipi.it> <4FF36438.2030902@FreeBSD.org> <4FF3E2C4.7050701@FreeBSD.org> <4FF3FB14.8020006@FreeBSD.org> <4FF402D1.4000505@FreeBSD.org> <20120704091241.GA99164@onelab2.iet.unipi.it> <4FF412B9.3000406@FreeBSD.org> <20120704154856.GC3680@onelab2.iet.unipi.it> <4FF59955.5090406@FreeBSD.org> <20120706061126.GA65432@onelab2.iet.unipi.it> <500452A5.3070501@FreeBSD.org> <500511A6.9010808@gmail.com> In-Reply-To: <500511A6.9010808@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Doug Barton , Luigi Rizzo , net@freebsd.org Subject: Re: FreeBSD 10G forwarding performance @Intel 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, 17 Jul 2012 07:32:40 -0000 On 17.07.2012 11:17, Hooman Fazaeli wrote: > May be slightly off-topic, but do you have tested (or have plans to test ) > with bidirectional traffic? Situation with bi-directional traffic is better (not sure how much). I'm intentionally not testing this case to discover rough cases (like contested interface counters) faster. Here is statistics from one of the machines running in production * E5645 * Intel 82599 * HT turned on (so 16 out of 24 cores are used) * Modified Intel drivers * 8.3-S kernel with interface rlock patch * ipfw counters eliminated * global forwarding counters not eliminated (-another 100-200 kpps) * route locking eliminated (modified version of original patch in the first message) * 8 vlans * IPv4 traffic * 4-8 firewall rules to pass http://static.ipfw.ru/images/degas_pps.png http://static.ipfw.ru/images/degas_traffic.png http://static.ipfw.ru/images/degas_cpu.png -- WBR, Alexander From owner-freebsd-net@FreeBSD.ORG Tue Jul 17 08:38:29 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 16B6E106564A; Tue, 17 Jul 2012 08:38:29 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from dhcp170-36-red.yandex.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with ESMTP id D173514DC0D; Tue, 17 Jul 2012 08:38:27 +0000 (UTC) Message-ID: <50052419.7010601@FreeBSD.org> Date: Tue, 17 Jul 2012 12:36:41 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120511 Thunderbird/12.0.1 MIME-Version: 1.0 To: Luigi Rizzo References: <4FF36438.2030902@FreeBSD.org> <4FF3E2C4.7050701@FreeBSD.org> <4FF3FB14.8020006@FreeBSD.org> <4FF402D1.4000505@FreeBSD.org> <20120704091241.GA99164@onelab2.iet.unipi.it> <4FF412B9.3000406@FreeBSD.org> <20120704154856.GC3680@onelab2.iet.unipi.it> <4FF59955.5090406@FreeBSD.org> <20120706061126.GA65432@onelab2.iet.unipi.it> <500452A5.3070501@FreeBSD.org> <20120716212249.GA14607@onelab2.iet.unipi.it> In-Reply-To: <20120716212249.GA14607@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Doug Barton , net@freebsd.org Subject: Re: FreeBSD 10G forwarding performance @Intel 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, 17 Jul 2012 08:38:29 -0000 On 17.07.2012 01:22, Luigi Rizzo wrote: > On Mon, Jul 16, 2012 at 09:43:01PM +0400, Alexander V. Chernikov wrote: >> On 06.07.2012 10:11, Luigi Rizzo wrote: >>> On Thu, Jul 05, 2012 at 05:40:37PM +0400, Alexander V. Chernikov wrote: >>>> On 04.07.2012 19:48, Luigi Rizzo wrote: > well, it seems that the counters are costing some 10% which is > not negligible (60ns per packet according to your test). > Also i'd be curious if you get better savings if you > have actual conflicts on the rulesets (e.g. what happens > with a ruleset that has, say, ten "count ip from any to any" rules) ? It is a bit difficult to get _exact_ performance numbers since 0.5% of linerate is ~ 70kpps, however 1.98 MPPS >> net.inet.ip.fw.update_counters=1 >> net.inet.ip.fw.enable=1 1.67 MPPS .. And here it is time to check ipfw rmlock performance another time, since we're acquiring recursive rmlock (pfil) and rwlock (ipfw) twice. input (ix0) output packets errs idrops bytes packets errs bytes colls 1664518 0 0 109910406 1664280 0 110055646 0 1664155 0 0 110018508 1664960 0 109921738 0 1663795 0 0 109839018 1664618 0 109965576 0 00100 count ip from any to any 1633118 22691 0 109539808 1621567 0 107402164 0 1625215 42836 0 110080554 1625638 0 107257950 0 1630848 34315 0 109932628 1631634 0 72449482 0 1613686 44167 0 109493942 1613811 0 142363996 0 1613387 53236 0 110075314 1614144 0 106479880 0 1611789 52348 0 109932904 1611600 0 106542318 0 1608327 56371 0 109947824 1608218 0 106229134 0 1615790 50527 0 110015368 1615528 0 106638914 0 1613453 50508 0 109872060 1614115 0 72118650 0 1614382 50955 0 109957958 1613808 0 141208126 0 1612053 54185 0 110002138 1611855 0 106490270 0 1538015 13138 0 102872260 1547403 0 102004436 0 1538084 0 0 101536936 1538034 0 66189600 0 1536305 0 0 101456028 1533714 0 101844506 0 1537533 0 0 101458596 1533775 0 101425338 0 00200 count ip from any to any 1529260 6840 0 101471016 1526825 0 100819632 0 1532496 5926 0 101540068 1534299 0 101292096 0 1532535 4412 0 101596090 1531906 0 101148828 0 1527551 9545 0 101488912 1527051 0 100957332 0 1538293 1523 0 101655604 1539942 0 101557938 0 1536673 0 0 84887698 1537473 0 69175150 0 1538330 0 0 118127042 1537831 0 134094698 0 .. 00300 count ip from any to any 1481474 0 0 97944746 1481326 0 67132158 0 1489185 2409 0 98413408 1480661 0 128797966 0 1476976 9604 0 98221830 1478449 0 97810444 0 1476286 12574 0 98464756 1479253 0 97638972 0 1483221 10545 0 98451838 1479954 0 97677840 0 So (very rought), First rule: 0.25-0.35MPPS (10-15% overall performance) Second rule: 0.05MPPS Third rule: 0.11MPPS (!) >> Additionally, I've got (from my previous pcpu attempt) a small patch >> permitting ipfw to re-use rule map allocation instead of reallocating >> on every rule. This saves a bit of system time: >> >> loading 20k rules with ipfw binary gives us: >> 5.1s system time before and 4.1s system time after. > > not bad but in this case i wonder if one wouldn't > get much higher savings by support multiple rule loading with a > single syscall. The format used in IPFW3 should help that. This seems to be more reasonable in general. So, skipping this patch? > > cheers > luigi > From owner-freebsd-net@FreeBSD.ORG Tue Jul 17 09:40:19 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id C11E81065672; Tue, 17 Jul 2012 09:40:19 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from dhcp170-36-red.yandex.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with ESMTP id 1C8AC14EE43; Tue, 17 Jul 2012 09:40:17 +0000 (UTC) Message-ID: <50053297.8060008@FreeBSD.org> Date: Tue, 17 Jul 2012 13:38:31 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120511 Thunderbird/12.0.1 MIME-Version: 1.0 To: Luigi Rizzo References: <4FF36438.2030902@FreeBSD.org> <4FF3E2C4.7050701@FreeBSD.org> <4FF3FB14.8020006@FreeBSD.org> <4FF402D1.4000505@FreeBSD.org> <20120704091241.GA99164@onelab2.iet.unipi.it> <4FF412B9.3000406@FreeBSD.org> <20120704154856.GC3680@onelab2.iet.unipi.it> <4FF59955.5090406@FreeBSD.org> <20120706061126.GA65432@onelab2.iet.unipi.it> <500452A5.3070501@FreeBSD.org> <20120716212249.GA14607@onelab2.iet.unipi.it> <50052419.7010601@FreeBSD.org> In-Reply-To: <50052419.7010601@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------000002080600050305070803" Cc: Doug Barton , net@freebsd.org Subject: Re: FreeBSD 10G forwarding performance @Intel 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, 17 Jul 2012 09:40:20 -0000 This is a multi-part message in MIME format. --------------000002080600050305070803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 17.07.2012 12:36, Alexander V. Chernikov wrote: > On 17.07.2012 01:22, Luigi Rizzo wrote: >> On Mon, Jul 16, 2012 at 09:43:01PM +0400, Alexander V. Chernikov wrote: >>> On 06.07.2012 10:11, Luigi Rizzo wrote: >>>> On Thu, Jul 05, 2012 at 05:40:37PM +0400, Alexander V. Chernikov wrote: >>>>> On 04.07.2012 19:48, Luigi Rizzo wrote: > >> well, it seems that the counters are costing some 10% which is >> not negligible (60ns per packet according to your test). >> Also i'd be curious if you get better savings if you >> have actual conflicts on the rulesets (e.g. what happens >> with a ruleset that has, say, ten "count ip from any to any" rules) ? > > It is a bit difficult to get _exact_ performance numbers since 0.5% of > linerate is ~ 70kpps, however > > 1.98 MPPS > >> net.inet.ip.fw.update_counters=1 > >> net.inet.ip.fw.enable=1 > 1.67 MPPS > > .. And here it is time to check ipfw rmlock performance another time, > since we're acquiring recursive rmlock (pfil) and rwlock (ipfw) twice. Merged r234648 for optimized rmlocks + conversion code attached. .. No significant improvement: The same 240kpps loss as in first test. 2123542 0 0 140309220 2125793 0 191227258 0 2125316 0 0 140167332 2119988 0 140427764 0 2121195 0 0 140353100 2126753 0 140264154 0 1995783 64677 0 137285216 1987194 0 132939934 0 1929111 170532 0 139248154 1927044 0 127285506 0 1905240 213804 0 140059092 1906731 0 78969668 0 1908064 219536 0 140444988 1907710 0 173344532 0 1906948 218554 0 140365550 1906791 0 79015778 0 1910961 214023 0 140395374 1911046 0 173126686 0 1913418 211265 0 140275990 1913272 0 126596628 0 Another try without these changes: 2141665 0 0 141533920 2143295 0 141662810 0 2141647 0 0 141536144 2142662 0 89849076 0 2143523 0 0 113655814 2142859 0 89734352 0 2024970 1528 0 164095778 2011710 0 241024066 0 1905563 239180 0 141749498 1909889 0 83090452 0 1906343 237516 0 141518736 1903779 0 168894600 0 1907890 235413 0 141558608 1907365 0 126036784 0 ... 1894339 1267 0 125099880 1892903 0 125032806 0 1885989 0 0 124627036 1894571 0 82456512 0 1889637 0 0 124735294 1890231 0 167681224 0 -- WBR, Alexander --------------000002080600050305070803 Content-Type: text/plain; charset=UTF-8; name="ipfw_rmlocks.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ipfw_rmlocks.diff" Index: sys/netinet/ipfw/ip_fw_private.h =================================================================== --- sys/netinet/ipfw/ip_fw_private.h (revision 234657) +++ sys/netinet/ipfw/ip_fw_private.h (working copy) @@ -226,7 +226,7 @@ struct ip_fw_chain { spinlock_t rwmtx; spinlock_t uh_lock; #else - struct rwlock rwmtx; + struct rmlock st_lock; /* chain lock */ struct rwlock uh_lock; /* lock for upper half */ #endif uint32_t id; /* ruleset id */ @@ -241,21 +241,21 @@ struct sockopt; /* used by tcp_var.h */ */ #define IPFW_LOCK_INIT(_chain) do { \ - rw_init(&(_chain)->rwmtx, "IPFW static rules"); \ + rm_init(&(_chain)->st_lock, "IPFW static rules"); \ rw_init(&(_chain)->uh_lock, "IPFW UH lock"); \ } while (0) #define IPFW_LOCK_DESTROY(_chain) do { \ - rw_destroy(&(_chain)->rwmtx); \ + rm_destroy(&(_chain)->st_lock); \ rw_destroy(&(_chain)->uh_lock); \ } while (0) -#define IPFW_WLOCK_ASSERT(_chain) rw_assert(&(_chain)->rwmtx, RA_WLOCKED) +#define IPFW_WLOCK_ASSERT(_chain) rm_wowned(&(_chain)->st_lock) -#define IPFW_RLOCK(p) rw_rlock(&(p)->rwmtx) -#define IPFW_RUNLOCK(p) rw_runlock(&(p)->rwmtx) -#define IPFW_WLOCK(p) rw_wlock(&(p)->rwmtx) -#define IPFW_WUNLOCK(p) rw_wunlock(&(p)->rwmtx) +#define IPFW_RLOCK(p) rm_rlock(&(p)->st_lock, &tracker) +#define IPFW_RUNLOCK(p) rm_runlock(&(p)->st_lock, &tracker) +#define IPFW_WLOCK(p) rm_wlock(&(p)->st_lock) +#define IPFW_WUNLOCK(p) rm_wunlock(&(p)->st_lock) #define IPFW_UH_RLOCK(p) rw_rlock(&(p)->uh_lock) #define IPFW_UH_RUNLOCK(p) rw_runlock(&(p)->uh_lock) Index: sys/netinet/ipfw/ip_dn_glue.c =================================================================== --- sys/netinet/ipfw/ip_dn_glue.c (revision 234657) +++ sys/netinet/ipfw/ip_dn_glue.c (working copy) @@ -42,6 +42,7 @@ #include #include #include +#include #include #include #include Index: sys/netinet/ipfw/ip_fw_log.c =================================================================== --- sys/netinet/ipfw/ip_fw_log.c (revision 234657) +++ sys/netinet/ipfw/ip_fw_log.c (working copy) @@ -41,6 +41,8 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include +#include #include #include #include Index: sys/netinet/ipfw/ip_fw_sockopt.c =================================================================== --- sys/netinet/ipfw/ip_fw_sockopt.c (revision 234657) +++ sys/netinet/ipfw/ip_fw_sockopt.c (working copy) @@ -49,6 +49,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -944,6 +945,7 @@ ipfw_ctl(struct sockopt *sopt) uint32_t opt; char xbuf[128]; ip_fw3_opheader *op3 = NULL; + struct rm_priotracker tracker; /* rmlock tracker */ error = priv_check(sopt->sopt_td, PRIV_NETINET_IPFW); if (error) Index: sys/netinet/ipfw/ip_fw_nat.c =================================================================== --- sys/netinet/ipfw/ip_fw_nat.c (revision 234657) +++ sys/netinet/ipfw/ip_fw_nat.c (working copy) @@ -35,6 +35,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #define IPFW_INTERNAL /* Access to protected data structures in ip_fw.h. */ @@ -210,6 +211,7 @@ ipfw_nat(struct ip_fw_args *args, struct cfg_nat * int ldt, retval, found; struct ip_fw_chain *chain; char *c; + struct rm_priotracker tracker; /* rmlock tracker */ ldt = 0; retval = 0; @@ -493,6 +495,7 @@ ipfw_nat_get_cfg(struct sockopt *sopt) struct cfg_spool *s; char *data; int gencnt, nat_cnt, len, error; + struct rm_priotracker tracker; /* rmlock tracker */ nat_cnt = 0; len = sizeof(nat_cnt); @@ -551,6 +554,7 @@ ipfw_nat_get_log(struct sockopt *sopt) struct cfg_nat *ptr; int i, size; struct ip_fw_chain *chain; + struct rm_priotracker tracker; /* rmlock tracker */ chain = &V_layer3_chain; Index: sys/netinet/ipfw/ip_fw_dynamic.c =================================================================== --- sys/netinet/ipfw/ip_fw_dynamic.c (revision 234657) +++ sys/netinet/ipfw/ip_fw_dynamic.c (working copy) @@ -46,6 +46,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include Index: sys/netinet/ipfw/ip_fw_table.c =================================================================== --- sys/netinet/ipfw/ip_fw_table.c (revision 234657) +++ sys/netinet/ipfw/ip_fw_table.c (working copy) @@ -52,6 +52,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include /* ip_fw.h requires IFNAMSIZ */ #include Index: sys/netinet/ipfw/ip_dn_io.c =================================================================== --- sys/netinet/ipfw/ip_dn_io.c (revision 234657) +++ sys/netinet/ipfw/ip_dn_io.c (working copy) @@ -42,6 +42,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include Index: sys/netinet/ipfw/ip_fw2.c =================================================================== --- sys/netinet/ipfw/ip_fw2.c (revision 234657) +++ sys/netinet/ipfw/ip_fw2.c (working copy) @@ -52,6 +52,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -907,6 +908,7 @@ ipfw_chk(struct ip_fw_args *args) int is_ipv4 = 0; int done = 0; /* flag to exit the outer loop */ + struct rm_priotracker tracker; /* rmlock tracker */ if (m->m_flags & M_SKIP_FIREWALL || (! V_ipfw_vnet_ready)) return (IP_FW_PASS); /* accept */ Index: sys/netinet/ipfw/ip_dummynet.c =================================================================== --- sys/netinet/ipfw/ip_dummynet.c (revision 234657) +++ sys/netinet/ipfw/ip_dummynet.c (working copy) @@ -44,6 +44,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include Index: sys/netgraph/ng_ipfw.c =================================================================== --- sys/netgraph/ng_ipfw.c (revision 234657) +++ sys/netgraph/ng_ipfw.c (working copy) @@ -33,6 +33,7 @@ #include #include #include +#include #include #include #include Index: sys/net/if_ethersubr.c =================================================================== --- sys/net/if_ethersubr.c (revision 234657) +++ sys/net/if_ethersubr.c (working copy) @@ -41,6 +41,7 @@ #include #include #include +#include #include #include #include --------------000002080600050305070803-- From owner-freebsd-net@FreeBSD.ORG Tue Jul 17 10:35:12 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 1E3C2106566C; Tue, 17 Jul 2012 10:35:12 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from dhcp170-36-red.yandex.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with ESMTP id 7F2C7151915; Tue, 17 Jul 2012 10:35:10 +0000 (UTC) Message-ID: <50053F74.7040101@FreeBSD.org> Date: Tue, 17 Jul 2012 14:33:24 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120511 Thunderbird/12.0.1 MIME-Version: 1.0 To: Konstantin Belousov References: <4FF36438.2030902@FreeBSD.org> <4FF3E2C4.7050701@FreeBSD.org> <4FF3FB14.8020006@FreeBSD.org> <4FF402D1.4000505@FreeBSD.org> <20120704091241.GA99164@onelab2.iet.unipi.it> <4FF412B9.3000406@FreeBSD.org> <20120704154856.GC3680@onelab2.iet.unipi.it> <4FF59955.5090406@FreeBSD.org> <20120706061126.GA65432@onelab2.iet.unipi.it> <500452A5.3070501@FreeBSD.org> <20120716232352.GE2676@deviant.kiev.zoral.com.ua> In-Reply-To: <20120716232352.GE2676@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Doug Barton , Luigi Rizzo , net@freebsd.org Subject: Re: FreeBSD 10G forwarding performance @Intel 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, 17 Jul 2012 10:35:12 -0000 On 17.07.2012 03:23, Konstantin Belousov wrote: > On Mon, Jul 16, 2012 at 09:43:01PM +0400, Alexander V. Chernikov wrote: >> On 06.07.2012 10:11, Luigi Rizzo wrote: >>> On Thu, Jul 05, 2012 at 05:40:37PM +0400, Alexander V. Chernikov wrote: >>>> On 04.07.2012 19:48, Luigi Rizzo wrote: >>> the thing discussed a few years ago (at least the one i took out of the >>> discussion) was that the counter fields in rules should hold the >>> index of a per-cpu counter associated to the rule. So CTR_INC(rule->ctr) >>> becomes something like pcpu->ipfw_ctrs[rule->ctr]++ >>> Once you create a new rule you also grab one free index from ipfw_ctrs[], >>> and the same should go for dummynet counters. >> >> Old kernel from previous letters, same setup: >> >> net.inet.ip.fw.enable=0 >> 2.3 MPPS >> net.inet.ip.fw.update_counters=0 >> net.inet.ip.fw.enable=1 >> 1.93MPPS >> net.inet.ip.fw.update_counters=1 >> 1.74MPPS >> >> Kernel with ipfw pcpu counters: >> >> net.inet.ip.fw.enable=0 >> 2.3 MPPS >> net.inet.ip.fw.update_counters=0 >> net.inet.ip.fw.enable=1 >> 1.93MPPS >> net.inet.ip.fw.update_counters=1 >> 1.93MPPS >> >> Counters seems to be working without any (significant) overhead. >> (Maybe I'm wrong somewhere?) > I do not think that your 'per-cpu' counter are correct. The thread > migration or rescheduling causes the fetch or update of the wrong It is typical in networking stack to bind interface queues to CPUs. It is done by netisr code and some network drivers like ixgbe. (And usually you should do it by hand if you want to achieve maximum performance). > per-cpu structure. This allows parallel updates with undefined > consequences. Yes. However, current ipfw counters implementation is not protected by any lock either, so I'm not sure if we really need to provide _very_ fine-graded counters. > > As a lowest thing to do, you need to disable preeemption around counter > structure dereference and increment. Same test with critical_enter() and critical_exit(): packets errs idrops bytes packets errs bytes colls 2412016 0 0 159027422 2413575 0 98996894 0 2412603 0 0 159762580 2413196 0 343078548 0 2413501 0 0 159094602 2411561 0 159208034 0 2413818 0 0 158894876 2412041 0 159579354 0 2411331 0 0 159867612 2412699 0 98690770 0 2413578 0 0 159565910 2413256 0 220508472 0 net.inet.ip.fw.update_counters=0 net.inet.ip.fw.enable=1 2109719 200318 0 155246592 2101593 0 141714254 0 2043039 373932 0 159586476 2042970 0 135004566 0 2042629 371124 0 159429254 2042308 0 84790780 0 packets errs idrops bytes packets errs bytes colls 2033687 0 0 134218324 2034435 0 134524224 0 2044290 0 0 134721534 2043947 0 85143014 0 2047714 0 0 135502190 2050383 0 85434406 0 net.inet.ip.fw.update_counters=0 2008526 0 0 132737890 2009535 0 281671228 0 1977217 13550 0 132278298 1968571 0 130585076 0 1975823 43522 0 133355986 1973620 0 130319542 0 1974159 40715 0 133124772 1977259 0 130552612 0 1969801 42073 0 132911194 1969426 0 130451906 0 1964142 21919 0 131242870 1966925 0 129959256 0 1961748 0 0 129548688 1966168 0 82793086 0 So, overhead (~80kpps) is now more observable. Not sure if this is reasonable. -- WBR, Alexander From owner-freebsd-net@FreeBSD.ORG Tue Jul 17 10:51:52 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1FA01065674; Tue, 17 Jul 2012 10:51:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 7BFFF8FC15; Tue, 17 Jul 2012 10:51:52 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6HApwL8065231; Tue, 17 Jul 2012 13:51:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q6HApjiA022129; Tue, 17 Jul 2012 13:51:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6HApj6C022128; Tue, 17 Jul 2012 13:51:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 17 Jul 2012 13:51:45 +0300 From: Konstantin Belousov To: "Alexander V. Chernikov" Message-ID: <20120717105145.GH2676@deviant.kiev.zoral.com.ua> References: <4FF3FB14.8020006@FreeBSD.org> <4FF402D1.4000505@FreeBSD.org> <20120704091241.GA99164@onelab2.iet.unipi.it> <4FF412B9.3000406@FreeBSD.org> <20120704154856.GC3680@onelab2.iet.unipi.it> <4FF59955.5090406@FreeBSD.org> <20120706061126.GA65432@onelab2.iet.unipi.it> <500452A5.3070501@FreeBSD.org> <20120716232352.GE2676@deviant.kiev.zoral.com.ua> <50053F74.7040101@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="D6IIOQQv2Iwyp54J" Content-Disposition: inline In-Reply-To: <50053F74.7040101@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Doug Barton , Luigi Rizzo , net@freebsd.org Subject: Re: FreeBSD 10G forwarding performance @Intel 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, 17 Jul 2012 10:51:53 -0000 --D6IIOQQv2Iwyp54J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 17, 2012 at 02:33:24PM +0400, Alexander V. Chernikov wrote: > On 17.07.2012 03:23, Konstantin Belousov wrote: > >On Mon, Jul 16, 2012 at 09:43:01PM +0400, Alexander V. Chernikov wrote: > >>On 06.07.2012 10:11, Luigi Rizzo wrote: > >>>On Thu, Jul 05, 2012 at 05:40:37PM +0400, Alexander V. Chernikov wrote: > >>>>On 04.07.2012 19:48, Luigi Rizzo wrote: > >>>the thing discussed a few years ago (at least the one i took out of the > >>>discussion) was that the counter fields in rules should hold the > >>>index of a per-cpu counter associated to the rule. So CTR_INC(rule->ct= r) > >>>becomes something like pcpu->ipfw_ctrs[rule->ctr]++ > >>>Once you create a new rule you also grab one free index from ipfw_ctrs= [], > >>>and the same should go for dummynet counters. > >> > >>Old kernel from previous letters, same setup: > >> > >>net.inet.ip.fw.enable=3D0 > >>2.3 MPPS > >>net.inet.ip.fw.update_counters=3D0 > >>net.inet.ip.fw.enable=3D1 > >>1.93MPPS > >>net.inet.ip.fw.update_counters=3D1 > >>1.74MPPS > >> > >>Kernel with ipfw pcpu counters: > >> > >>net.inet.ip.fw.enable=3D0 > >>2.3 MPPS > >>net.inet.ip.fw.update_counters=3D0 > >>net.inet.ip.fw.enable=3D1 > >>1.93MPPS > >>net.inet.ip.fw.update_counters=3D1 > >>1.93MPPS > >> > >>Counters seems to be working without any (significant) overhead. > >>(Maybe I'm wrong somewhere?) >=20 > >I do not think that your 'per-cpu' counter are correct. The thread > >migration or rescheduling causes the fetch or update of the wrong > It is typical in networking stack to bind interface queues to CPUs. > It is done by netisr code and some network drivers like ixgbe. > (And usually you should do it by hand if you want to achieve maximum=20 > performance). Binding is not enough to guarantee safe update. It elimminates some issues, like changing curcpu, but does not prevents two threads from interwinding the execution of read/incr/write sequences. > >per-cpu structure. This allows parallel updates with undefined > >consequences. > Yes. However, current ipfw counters implementation is not protected by=20 > any lock either, so I'm not sure if we really need to provide _very_=20 > fine-graded counters. > > >=20 > >As a lowest thing to do, you need to disable preeemption around counter > >structure dereference and increment. > Same test with critical_enter() and critical_exit(): >=20 > packets errs idrops bytes packets errs bytes colls > 2412016 0 0 159027422 2413575 0 98996894 0 > 2412603 0 0 159762580 2413196 0 343078548 0 > 2413501 0 0 159094602 2411561 0 159208034 0 > 2413818 0 0 158894876 2412041 0 159579354 0 > 2411331 0 0 159867612 2412699 0 98690770 0 > 2413578 0 0 159565910 2413256 0 220508472 0 > net.inet.ip.fw.update_counters=3D0 > net.inet.ip.fw.enable=3D1 > 2109719 200318 0 155246592 2101593 0 141714254 0 > 2043039 373932 0 159586476 2042970 0 135004566 0 > 2042629 371124 0 159429254 2042308 0 84790780 0 > packets errs idrops bytes packets errs bytes colls > 2033687 0 0 134218324 2034435 0 134524224 0 > 2044290 0 0 134721534 2043947 0 85143014 0 > 2047714 0 0 135502190 2050383 0 85434406 0 > net.inet.ip.fw.update_counters=3D0 > 2008526 0 0 132737890 2009535 0 281671228 0 > 1977217 13550 0 132278298 1968571 0 130585076 0 > 1975823 43522 0 133355986 1973620 0 130319542 0 > 1974159 40715 0 133124772 1977259 0 130552612 0 > 1969801 42073 0 132911194 1969426 0 130451906 0 > 1964142 21919 0 131242870 1966925 0 129959256 0 > 1961748 0 0 129548688 1966168 0 82793086 0 >=20 > So, overhead (~80kpps) is now more observable. Not sure if this is=20 > reasonable. >=20 >=20 > --=20 > WBR, Alexander --D6IIOQQv2Iwyp54J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAFQ8EACgkQC3+MBN1Mb4gH5ACg814l+k+mfbFT/LUaM4h461XY 6i8AoPNN7YqNn43Y2dusQOytppKGSmVx =iAk7 -----END PGP SIGNATURE----- --D6IIOQQv2Iwyp54J-- From owner-freebsd-net@FreeBSD.ORG Tue Jul 17 10:55:28 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 1C157106564A; Tue, 17 Jul 2012 10:55:28 +0000 (UTC) (envelope-from venkatduvvuru.ml@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id B61858FC0C; Tue, 17 Jul 2012 10:55:27 +0000 (UTC) Received: by ggnm2 with SMTP id m2so268224ggn.13 for ; Tue, 17 Jul 2012 03:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T6+Axv4ldeSB3i/M4iXJZyXwydEZSuVudE9HAf85MsE=; b=BA1Jldpc9bFFAe4Gb4pP2C+p5IS1knnBgu/odRCJ1M9j+aozkXCJrlh1jDGu2M67+o s+6sysRAjV6j1oNdhdsRUWNu0LH2+Zi9abfwkMrZ4SaFtzB386xmtJUV1UcRgrVo04r4 5l45Y1NeNXKLm3Z5Ko17uqmjVsq8pbY8HyxKSerA3LiyINNzlDbgrkvYMYrjAjKRwqjc 8GFWO2nzcW61ix7wq06YFKjcxrA4CCn2hJQhf0v5i1BhcFcZ+SL6aKadBLrRDONeC4QF OSGVd6H67hE/uq8bDZQzXiLnFvhI9OH83PVYqIOKFfEveuKawFwbN1B2JJMUR++tOQI3 r5tg== MIME-Version: 1.0 Received: by 10.50.184.198 with SMTP id ew6mr903852igc.27.1342522526659; Tue, 17 Jul 2012 03:55:26 -0700 (PDT) Received: by 10.64.106.202 with HTTP; Tue, 17 Jul 2012 03:55:26 -0700 (PDT) In-Reply-To: <174885088.20120517122111@serebryakov.spb.ru> References: <174885088.20120517122111@serebryakov.spb.ru> Date: Tue, 17 Jul 2012 16:25:26 +0530 Message-ID: From: Venkat Duvvuru To: lev@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: IPv6 flowid hash calculation 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, 17 Jul 2012 10:55:28 -0000 Hi Lev, Thanks for your response. I browsed through Freebsd's network stack code and here is my observation. If driver sets the queue index in receive path and sets FLOWID flag in mbuf then this information will be stored in tcp control block and the same queue index will be used while transmitting and further in the stack, the same information will be used irrespective of enabling and disabling FLOWTABLE. But I observed that irrespective of on which queue, the ipv6 packet is received, transmit is happening always on queue 0. /Venkat On Thu, May 17, 2012 at 1:51 PM, Lev Serebryakov wrote: > Hello, Venkat. > You wrote 16 =D0=BC=D0=B0=D1=8F 2012 =D0=B3., 10:09:29: > > VD> This question is related to the hash calculation done as part of > selecting > VD> the transmit queue for IPv6 traffic. > VD> I observed that no matter how many queues you use in the driver, the = tx > VD> traffic is always coming on queue 0. > VD> Did anybody else observed this behaviour? > VD> Note: IPv4 traffic is coming on all the tx queues. > flowid is specified by MS & Intel only for IPv4 traffic (hash > function, which is used to determine queue is defined only for IPv4 > packet header). All other traffic (PPPoE, IPv6, etc.) goes into queue > 0. There is nothing could be done on driver level, it is firmware (and > "standard") problem. > > I was told, that top-level ("server-grade") 1G and 10G Intel NICs > have configurable user-defined filters (think: firewall and QoS in > hardware), and, may be, it could be done on this level, but I don't > know any open-source drivers, which support this feature. > > -- > // Black Lion AKA Lev Serebryakov > > From owner-freebsd-net@FreeBSD.ORG Tue Jul 17 13:21:59 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4529A106564A; Tue, 17 Jul 2012 13:21:59 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 985888FC17; Tue, 17 Jul 2012 13:21:58 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q6HDLtxn023268; Tue, 17 Jul 2012 20:21:55 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <500566F3.9050101@rdtc.ru> Date: Tue, 17 Jul 2012 20:21:55 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Konstantin Belousov References: <4FF36438.2030902@FreeBSD.org> <4FF3E2C4.7050701@FreeBSD.org> <4FF3FB14.8020006@FreeBSD.org> <4FF402D1.4000505@FreeBSD.org> <20120704091241.GA99164@onelab2.iet.unipi.it> <4FF412B9.3000406@FreeBSD.org> <20120704154856.GC3680@onelab2.iet.unipi.it> <4FF59955.5090406@FreeBSD.org> <20120706061126.GA65432@onelab2.iet.unipi.it> <500452A5.3070501@FreeBSD.org> <20120716232352.GE2676@deviant.kiev.zoral.com.ua> In-Reply-To: <20120716232352.GE2676@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: Luigi Rizzo , Doug Barton , "Alexander V. Chernikov" , net@freebsd.org Subject: Re: FreeBSD 10G forwarding performance @Intel 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, 17 Jul 2012 13:21:59 -0000 17.07.2012 06:23, Konstantin Belousov ΠΙΫΕΤ: > I do not think that your 'per-cpu' counter are correct. The thread > migration or rescheduling causes the fetch or update of the wrong > per-cpu structure. This allows parallel updates with undefined > consequences. >From practical point of view, I'like to state that most of us do NOT need scientifically exact ipfw counters values when pushing hardware to its maximum. Personaly, I'd like to have tunable that gives me another 15% of speed at cost of bad ipfw counters I don't use anyway. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Wed Jul 18 06:56:17 2012 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 E3408106566C for ; Wed, 18 Jul 2012 06:56:17 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6023A8FC12 for ; Wed, 18 Jul 2012 06:56:17 +0000 (UTC) Received: by lbon10 with SMTP id n10so2133140lbo.13 for ; Tue, 17 Jul 2012 23:56:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=jO2ojx6ve52ifGojoVl+gKEEMOAi0Tvg1AemDASx+YA=; b=nX0E/sy9Bf6n9bVs8N52krxddokSYbpw1YJ1A7kORQECF1WTp82hGFjh1VBo1Ti2Je prmhMyMwvzK5SeDgh3UjHW6QAxDafaaak72fxObnsT3Dn82I+3bmKGF61YqtkiqJr9dQ X1BXiUHkdcW2rSjfKiGgfCOuW1uZ1p4vXWZ/m4WKDgZE32Ajj598q6b4SSE7AgIcEbry v1XxEVSN720Yarp+T26RIFEJbDh8VW1xVY42EPD1xMEuTb6wnS4yrgwHMnu/uLXtxlgb 5EbyWU7ft3Zv63zqRMcKxmZj8MCoWY6h3N3q1zKo+LHsSkjHQvMCDDuTI3Qb5rFDJ3/b GYyw== Received: by 10.152.112.233 with SMTP id it9mr1985744lab.40.1342594576185; Tue, 17 Jul 2012 23:56:16 -0700 (PDT) Received: from zont-osx.local (ppp95-165-134-208.pppoe.spdop.ru. [95.165.134.208]) by mx.google.com with ESMTPS id s3sm4544740lbk.11.2012.07.17.23.56.14 (version=SSLv3 cipher=OTHER); Tue, 17 Jul 2012 23:56:15 -0700 (PDT) Message-ID: <50065E0E.50903@zonov.org> Date: Wed, 18 Jul 2012 10:56:14 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" References: <5003EDC4.3050100@zonov.org> <50048A34.10304@zonov.org> In-Reply-To: <50048A34.10304@zonov.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQm5zSY/1y/ZB3mbXlEGZ9OSiNcjQvHgjj6uQQiib2qk43t2/wIpg/hSRWt+vmYYETUFPUT0 Subject: Re: panic: negative refcount 0xfffffe0007f1b4d4 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: Wed, 18 Jul 2012 06:56:18 -0000 On 7/17/12 1:40 AM, Andrey Zonov wrote: > On 7/16/12 2:32 PM, Andrey Zonov wrote: >> Hi, >> >> I've got about 30 machines which panic sometimes in different places but >> with the same panic message: "negative refcount 0xfffffe0007f1b4d4". >> They are running under 9.0-STABLE@r234600M. >> > [snip] >> >> Is this known issue? If it is not, I've got textdumps and can send to >> anyone who wants to help me. >> >> Thanks in advance. >> > > So, this is the one more ifa leak. > It happens when "goto again" is called in ip_output(), in my case under IPFIREWALL_FORWARD. I'm doing source routing with "ipfw fwd". There are no leaks with this patch applied: Index: sys/netinet/ip_output.c =================================================================== --- sys/netinet/ip_output.c (revision 234600) +++ sys/netinet/ip_output.c (working copy) @@ -203,6 +203,8 @@ again: * The address family should also be checked in case of sharing the * cache with IPv6. */ + if (ia != NULL) + ifa_free(&ia->ia_ifa); rte = ro->ro_rt; if (rte && ((rte->rt_flags & RTF_UP) == 0 || rte->rt_ifp == NULL || I also want to propose this patch: Index: sys/sys/refcount.h =================================================================== --- sys/sys/refcount.h (revision 234600) +++ sys/sys/refcount.h (working copy) @@ -51,6 +51,7 @@ static __inline void refcount_acquire(volatile u_int *count) { + KASSERT(*count < 0xffffff00, ("refcount %p is overflowed", count)); atomic_add_acq_int(count, 1); } It will give better diagnostic when refcount is overflowed, instead of "negative refcount". -- Andrey Zonov From owner-freebsd-net@FreeBSD.ORG Wed Jul 18 07:17:45 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 701D5106564A; Wed, 18 Jul 2012 07:17:45 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 431568FC16; Wed, 18 Jul 2012 07:17:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6I7HjYb076989; Wed, 18 Jul 2012 07:17:45 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6I7HikC076984; Wed, 18 Jul 2012 07:17:44 GMT (envelope-from yongari) Date: Wed, 18 Jul 2012 07:17:44 GMT Message-Id: <201207180717.q6I7HikC076984@freefall.freebsd.org> To: bas@area536.com, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/169826: [re] if_re no longer working in 9.x [regression] 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: Wed, 18 Jul 2012 07:17:45 -0000 Synopsis: [re] if_re no longer working in 9.x [regression] State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Wed Jul 18 07:16:40 UTC 2012 State-Changed-Why: 9.0-RELEASE came before 8.3-RELEASE so it lacks support for your controller. Use 9.1-BETA1 or stable/9 to get working network on FreeBSD 9. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Wed Jul 18 07:16:40 UTC 2012 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=169826 From owner-freebsd-net@FreeBSD.ORG Wed Jul 18 09:44:33 2012 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 A4D2B106566B for ; Wed, 18 Jul 2012 09:44:33 +0000 (UTC) (envelope-from dk311990@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 35CFD8FC16 for ; Wed, 18 Jul 2012 09:44:33 +0000 (UTC) Received: by eabm6 with SMTP id m6so501603eab.13 for ; Wed, 18 Jul 2012 02:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=cG41OCBECCxiMSOXUWgmhSh0X3eWetBeSl5rKu9mPR4=; b=i/4SASbKkDpgGwbLoBsQQejVjW2bqWwq9UDXsure5JAr5+kFK8ARV8Zq5qnCrFDKra M9VeSsUrY76179LyDGRSzm4GP0Z55R4t6lj7A3EUCXtED0W0yUyCCegiv+tVJQYjlI+j kWpC/XWsV0V6OzLgHyKRS8BjNunoCcPbtOv7Hzsf5zApmTi0NR6/sLdiPoriHeBTkyq3 vQXN5ww81AwRTgWae3nveU0t3hm0ahMPEKjNPOAByK8ESnXz3KWEIq8NX3c5a625w2Ge F/2yJ7CY08ro5txyedOU2PzOANSP80kojTUwt6aQG6lIcMRtwO1LiJ5ru0dZf2jBfkgJ uT+w== MIME-Version: 1.0 Received: by 10.14.175.5 with SMTP id y5mr2817132eel.40.1342604668184; Wed, 18 Jul 2012 02:44:28 -0700 (PDT) Received: by 10.14.99.14 with HTTP; Wed, 18 Jul 2012 02:44:28 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Jul 2012 15:14:28 +0530 Message-ID: From: Deepak Kumar To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: determine the nic pairs 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: Wed, 18 Jul 2012 09:44:33 -0000 Hi Enthusiast, I have a server which has around 20 nic interfaces. Some are connected port to port via cross cable and some are connected via a switch and few are not connected. (Let consider all are connected port to port) I want to find out the way so that I can determine the pairs efficiently. I assigned ip starting from 172.x.x.30 with netmask 255.255.255.0 I created as many sockets as there are interfaces with socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP) then I bind the all but one interfaces to the ip I gave using bind(sockfd, (struct sockaddr *)&in, sizeof(in)); where in is something like bzero(&in, sizeof(in)); in.sin_family = AF_INET; in.sin_port = htons(2074); in.sin_addr.s_addr = inet_addr("172.x.x.30+interfaceno"); and one left socket I did socket creation and using setsockopt I did int option = 1; setsockopt(sockfd[counter], SOL_SOCKET, SO_BROADCAST, &option, sizeof(option)); and do sendto(sockfd, arr, sizeof(arr), 0, (struct sockaddr *)&in, len); where in is bzero(&in, sizeof(in)); in.sin_family = AF_INET; in.sin_port = htons(2074); in.sin_addr.s_addr = inet_addr(172.x.x.255); Now I want to send the packet from one interface and who ever receive should be its partner. But when I do recvfrom for one socket it blocks and I am not able to implement timeout for it. select is not working as it need file discripter and socket call is returning struct socket. So how should I implement timeout in recvfrom or use there exist some equivalent of select for struct socket or any other way to implement this. PS: Ping is working fine in determining the pair but taking to much time. From owner-freebsd-net@FreeBSD.ORG Wed Jul 18 14:35:55 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id BB24D106564A; Wed, 18 Jul 2012 14:35:55 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from dhcp170-36-red.yandex.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with ESMTP id DD49214DF59; Wed, 18 Jul 2012 14:35:51 +0000 (UTC) Message-ID: <5006C959.5060506@FreeBSD.org> Date: Wed, 18 Jul 2012 18:34:01 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120511 Thunderbird/12.0.1 MIME-Version: 1.0 To: Luigi Rizzo References: <4FF36438.2030902@FreeBSD.org> <4FF3E2C4.7050701@FreeBSD.org> <4FF3FB14.8020006@FreeBSD.org> <4FF402D1.4000505@FreeBSD.org> <20120704091241.GA99164@onelab2.iet.unipi.it> <4FF412B9.3000406@FreeBSD.org> <20120704154856.GC3680@onelab2.iet.unipi.it> <4FF59955.5090406@FreeBSD.org> <20120706061126.GA65432@onelab2.iet.unipi.it> <500452A5.3070501@FreeBSD.org> <20120716212249.GA14607@onelab2.iet.unipi.it> <50052419.7010601@FreeBSD.org> <50053297.8060008@FreeBSD.org> In-Reply-To: <50053297.8060008@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------090809000406030208080301" Cc: Doug Barton , Gleb Smirnoff , net@freebsd.org Subject: Re: FreeBSD 10G forwarding performance @Intel 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: Wed, 18 Jul 2012 14:35:55 -0000 This is a multi-part message in MIME format. --------------090809000406030208080301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 17.07.2012 13:38, Alexander V. Chernikov wrote: > On 17.07.2012 12:36, Alexander V. Chernikov wrote: >> On 17.07.2012 01:22, Luigi Rizzo wrote: >>> On Mon, Jul 16, 2012 at 09:43:01PM +0400, Alexander V. Chernikov wrote: >>>> On 06.07.2012 10:11, Luigi Rizzo wrote: >>>>> On Thu, Jul 05, 2012 at 05:40:37PM +0400, Alexander V. Chernikov >>>>> wrote: >>>>>> On 04.07.2012 19:48, Luigi Rizzo wrote: >> >>> well, it seems that the counters are costing some 10% which is >>> not negligible (60ns per packet according to your test). >>> Also i'd be curious if you get better savings if you >>> have actual conflicts on the rulesets (e.g. what happens >>> with a ruleset that has, say, ten "count ip from any to any" rules) ? >> >> It is a bit difficult to get _exact_ performance numbers since 0.5% of >> linerate is ~ 70kpps, however >> >> 1.98 MPPS >> >> net.inet.ip.fw.update_counters=1 >> >> net.inet.ip.fw.enable=1 >> 1.67 MPPS >> >> .. And here it is time to check ipfw rmlock performance another time, >> since we're acquiring recursive rmlock (pfil) and rwlock (ipfw) twice. Try 2: We're acquiring pfil read lock every time while we run ipfw L3 hooks. Idea is to 1) make single pfil lock per vnet (instead of locking IPv4/IPv6 parts separately) 2) Use this lock in every ipfw vnet instance. Use spare u32 (on amd64) in ip_fw_args for indicating lock status. If we're called from pfil_run_hooks than we don't need to acquire read lock at all. If we're called from L2 code, than we use the same lock to achieve read locking (so ipfw effectively moves to rmlock). Advantage is the following: 2616383 0 0 172782796 2618097 0 104959874 0 input (ix0) output packets errs idrops bytes packets errs bytes colls 2616555 0 0 172800298 2614022 0 240882076 0 sysctl net.inet.ip.fw.enable=1 2579013 15020 0 172117070 2573027 0 103303742 0 2482512 133018 0 172839764 2482611 0 100384486 0 2488521 128616 0 172833196 2488436 0 100658014 0 2484547 132775 0 172998262 2485739 0 359364892 0 .. 2484005 0 0 200574354 2490405 0 164732208 0 So, now overhead is 120-130kpps instead of ~240 with dual locking. Patch attached. > > Merged r234648 for optimized rmlocks + conversion code attached. > > .. No significant improvement: > > > The same 240kpps loss as in first test. > > 2123542 0 0 140309220 2125793 0 191227258 0 > 2125316 0 0 140167332 2119988 0 140427764 0 > 2121195 0 0 140353100 2126753 0 140264154 0 > 1995783 64677 0 137285216 1987194 0 132939934 0 > 1929111 170532 0 139248154 1927044 0 127285506 0 > 1905240 213804 0 140059092 1906731 0 78969668 0 > 1908064 219536 0 140444988 1907710 0 173344532 0 > 1906948 218554 0 140365550 1906791 0 79015778 0 > 1910961 214023 0 140395374 1911046 0 173126686 0 > 1913418 211265 0 140275990 1913272 0 126596628 0 > > Another try without these changes: > > 2141665 0 0 141533920 2143295 0 141662810 0 > 2141647 0 0 141536144 2142662 0 89849076 0 > 2143523 0 0 113655814 2142859 0 89734352 0 > 2024970 1528 0 164095778 2011710 0 241024066 0 > 1905563 239180 0 141749498 1909889 0 83090452 0 > 1906343 237516 0 141518736 1903779 0 168894600 0 > 1907890 235413 0 141558608 1907365 0 126036784 0 > ... > 1894339 1267 0 125099880 1892903 0 125032806 0 > 1885989 0 0 124627036 1894571 0 82456512 0 > 1889637 0 0 124735294 1890231 0 167681224 0 > > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- WBR, Alexander --------------090809000406030208080301 Content-Type: text/plain; charset=UTF-8; name="ipfw_rmlock2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ipfw_rmlock2.diff" diff --git a/sys/net/if_ethersubr.c b/sys/net/if_ethersubr.c index 3231a8b..a357e87 100644 --- a/sys/net/if_ethersubr.c +++ b/sys/net/if_ethersubr.c @@ -41,6 +41,7 @@ #include #include #include +#include #include #include #include diff --git a/sys/net/pfil.c b/sys/net/pfil.c index df0e30f..0819ddc 100644 --- a/sys/net/pfil.c +++ b/sys/net/pfil.c @@ -61,6 +61,8 @@ static int pfil_list_remove(pfil_list_t *, LIST_HEAD(pfilheadhead, pfil_head); VNET_DEFINE(struct pfilheadhead, pfil_head_list); #define V_pfil_head_list VNET(pfil_head_list) +VNET_DEFINE(struct rmlock, pfil_lock); +#define V_pfil_lock VNET(pfil_lock) /* * pfil_run_hooks() runs the specified packet filter hooks. @@ -153,6 +155,12 @@ pfil_head_get(int type, u_long val) return (ph); } +struct rmlock * +pfil_lock_get() +{ + return &V_pfil_lock; +} + /* * pfil_add_hook() adds a function to the packet filter hook. the * flags are: @@ -294,6 +302,7 @@ static int vnet_pfil_init(const void *unused) { LIST_INIT(&V_pfil_head_list); + rm_init_flags(&V_pfil_lock, "PFil hook read/write mutex", RM_RECURSE); return (0); } @@ -304,6 +313,7 @@ static int vnet_pfil_uninit(const void *unused) { /* XXX should panic if list is not empty */ + rm_destroy(&V_pfil_lock); return 0; } diff --git a/sys/net/pfil.h b/sys/net/pfil.h index 6ac750a..6fd49fd 100644 --- a/sys/net/pfil.h +++ b/sys/net/pfil.h @@ -43,6 +43,7 @@ struct mbuf; struct ifnet; struct inpcb; + /* * The packet filter hooks are designed for anything to call them to * possibly intercept the packet. @@ -69,7 +70,7 @@ struct pfil_head { pfil_list_t ph_out; int ph_type; int ph_nhooks; - struct rmlock ph_lock; + struct rmlock *ph_plock; union { u_long phu_val; void *phu_ptr; @@ -90,8 +91,10 @@ int pfil_head_register(struct pfil_head *); int pfil_head_unregister(struct pfil_head *); struct pfil_head *pfil_head_get(int, u_long); +struct rmlock *pfil_lock_get(void); #define PFIL_HOOKED(p) ((p)->ph_nhooks > 0) +#if 0 #define PFIL_LOCK_INIT(p) \ rm_init_flags(&(p)->ph_lock, "PFil hook read/write mutex", RM_RECURSE) #define PFIL_LOCK_DESTROY(p) rm_destroy(&(p)->ph_lock) @@ -99,6 +102,15 @@ struct pfil_head *pfil_head_get(int, u_long); #define PFIL_WLOCK(p) rm_wlock(&(p)->ph_lock) #define PFIL_RUNLOCK(p, t) rm_runlock(&(p)->ph_lock, (t)) #define PFIL_WUNLOCK(p) rm_wunlock(&(p)->ph_lock) +#endif +#define PFIL_LOCK_INIT(p) \ + (p)->ph_plock = &V_pfil_lock +#define PFIL_LOCK_DESTROY(p) +#define PFIL_RLOCK(p, t) rm_rlock((p)->ph_plock, (t)) +#define PFIL_WLOCK(p) rm_wlock((p)->ph_plock) +#define PFIL_RUNLOCK(p, t) rm_runlock((p)->ph_plock, (t)) +#define PFIL_WUNLOCK(p) rm_wunlock((p)->ph_plock) + #define PFIL_LIST_LOCK() mtx_lock(&pfil_global_lock) #define PFIL_LIST_UNLOCK() mtx_unlock(&pfil_global_lock) diff --git a/sys/netinet/ipfw/ip_fw2.c b/sys/netinet/ipfw/ip_fw2.c index 7bb73b0..f995eda 100644 --- a/sys/netinet/ipfw/ip_fw2.c +++ b/sys/netinet/ipfw/ip_fw2.c @@ -52,6 +52,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -62,6 +63,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include @@ -912,6 +914,8 @@ ipfw_chk(struct ip_fw_args *args) int done = 0; /* flag to exit the outer loop */ + struct rm_priotracker tracker; + if (m->m_flags & M_SKIP_FIREWALL || (! V_ipfw_vnet_ready)) return (IP_FW_PASS); /* accept */ @@ -1178,9 +1182,11 @@ do { \ args->f_id.dst_port = dst_port = ntohs(dst_port); } - IPFW_RLOCK(chain); + if (args->locked == 0) + IPFW_RLOCK(chain); if (! V_ipfw_vnet_ready) { /* shutting down, leave NOW. */ - IPFW_RUNLOCK(chain); + if (args->locked == 0) + IPFW_RUNLOCK(chain); return (IP_FW_PASS); /* accept */ } if (args->rule.slot) { @@ -2394,7 +2400,8 @@ do { \ retval = IP_FW_DENY; printf("ipfw: ouch!, skip past end of rules, denying packet\n"); } - IPFW_RUNLOCK(chain); + if (args->locked == 0) + IPFW_RUNLOCK(chain); #ifdef __FreeBSD__ if (ucred_cache != NULL) crfree(ucred_cache); diff --git a/sys/netinet/ipfw/ip_fw_nat.c b/sys/netinet/ipfw/ip_fw_nat.c index dbeb254..67faa44 100644 --- a/sys/netinet/ipfw/ip_fw_nat.c +++ b/sys/netinet/ipfw/ip_fw_nat.c @@ -35,6 +35,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #define IPFW_INTERNAL /* Access to protected data structures in ip_fw.h. */ @@ -210,6 +211,7 @@ ipfw_nat(struct ip_fw_args *args, struct cfg_nat *t, struct mbuf *m) int ldt, retval, found; struct ip_fw_chain *chain; char *c; + struct rm_priotracker tracker; ldt = 0; retval = 0; @@ -268,7 +270,8 @@ ipfw_nat(struct ip_fw_args *args, struct cfg_nat *t, struct mbuf *m) found = 0; chain = &V_layer3_chain; - IPFW_RLOCK(chain); + if (args->locked == 0) + IPFW_RLOCK(chain); /* Check every nat entry... */ LIST_FOREACH(t, &chain->nat, _next) { if ((t->mode & PKT_ALIAS_SKIP_GLOBAL) != 0) @@ -281,7 +284,8 @@ ipfw_nat(struct ip_fw_args *args, struct cfg_nat *t, struct mbuf *m) break; } } - IPFW_RUNLOCK(chain); + if (args->locked == 0) + IPFW_RUNLOCK(chain); if (found != 1) { /* No instance found, return ignore */ args->m = mcl; @@ -493,6 +497,7 @@ ipfw_nat_get_cfg(struct sockopt *sopt) struct cfg_spool *s; char *data; int gencnt, nat_cnt, len, error; + struct rm_priotracker tracker; nat_cnt = 0; len = sizeof(nat_cnt); @@ -551,6 +556,7 @@ ipfw_nat_get_log(struct sockopt *sopt) struct cfg_nat *ptr; int i, size; struct ip_fw_chain *chain; + struct rm_priotracker tracker; chain = &V_layer3_chain; diff --git a/sys/netinet/ipfw/ip_fw_pfil.c b/sys/netinet/ipfw/ip_fw_pfil.c index c6d7688..6e6764e 100644 --- a/sys/netinet/ipfw/ip_fw_pfil.c +++ b/sys/netinet/ipfw/ip_fw_pfil.c @@ -143,6 +143,8 @@ again: args.m = *m0; args.oif = dir == DIR_OUT ? ifp : NULL; args.inp = inp; + /* We are locked by VNET pfil lock */ + args.locked = 1; ipfw = ipfw_chk(&args); *m0 = args.m; diff --git a/sys/netinet/ipfw/ip_fw_private.h b/sys/netinet/ipfw/ip_fw_private.h index 46d011c..977661f 100644 --- a/sys/netinet/ipfw/ip_fw_private.h +++ b/sys/netinet/ipfw/ip_fw_private.h @@ -95,6 +95,7 @@ struct ip_fw_args { * Otherwise, we locate the first rule >= rulenum:rule_id */ struct ipfw_rule_ref rule; /* match/restart info */ + uint32_t locked; /* True if chain is already locked */ struct ether_header *eh; /* for bridged packets */ @@ -226,7 +227,7 @@ struct ip_fw_chain { spinlock_t rwmtx; spinlock_t uh_lock; #else - struct rwlock rwmtx; + struct rmlock *rm_plock; /* Pointer to pfil lock */ struct rwlock uh_lock; /* lock for upper half */ #endif uint32_t id; /* ruleset id */ @@ -240,6 +241,7 @@ struct sockopt; /* used by tcp_var.h */ * so the variable and the macros must be here. */ +#if 0 #define IPFW_LOCK_INIT(_chain) do { \ rw_init(&(_chain)->rwmtx, "IPFW static rules"); \ rw_init(&(_chain)->uh_lock, "IPFW UH lock"); \ @@ -256,6 +258,23 @@ struct sockopt; /* used by tcp_var.h */ #define IPFW_RUNLOCK(p) rw_runlock(&(p)->rwmtx) #define IPFW_WLOCK(p) rw_wlock(&(p)->rwmtx) #define IPFW_WUNLOCK(p) rw_wunlock(&(p)->rwmtx) +#endif +#define IPFW_LOCK_INIT(_chain) do { \ + (_chain)->rm_plock = pfil_lock_get(); \ + rw_init(&(_chain)->uh_lock, "IPFW UH lock"); \ + } while (0) + +#define IPFW_LOCK_DESTROY(_chain) do { \ + (_chain)->rm_plock = NULL; \ + rw_destroy(&(_chain)->uh_lock); \ + } while (0) + +#define IPFW_WLOCK_ASSERT(_chain) rm_wowned((_chain)->rm_plock) + +#define IPFW_RLOCK(p) rm_rlock((p)->rm_plock, &tracker) +#define IPFW_RUNLOCK(p) rm_runlock((p)->rm_plock, &tracker) +#define IPFW_WLOCK(p) rm_wlock((p)->rm_plock) +#define IPFW_WUNLOCK(p) rm_wunlock((p)->rm_plock) #define IPFW_UH_RLOCK(p) rw_rlock(&(p)->uh_lock) #define IPFW_UH_RUNLOCK(p) rw_runlock(&(p)->uh_lock) diff --git a/sys/netinet/ipfw/ip_fw_sockopt.c b/sys/netinet/ipfw/ip_fw_sockopt.c index 0aecc2c..e744429 100644 --- a/sys/netinet/ipfw/ip_fw_sockopt.c +++ b/sys/netinet/ipfw/ip_fw_sockopt.c @@ -49,6 +49,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -943,6 +944,7 @@ ipfw_ctl(struct sockopt *sopt) u_int32_t rulenum[2]; uint32_t opt; char xbuf[128]; + struct rm_priotracker tracker; ip_fw3_opheader *op3 = NULL; error = priv_check(sopt->sopt_td, PRIV_NETINET_IPFW); diff --git a/sys/netinet/ipfw/ip_fw_table.c b/sys/netinet/ipfw/ip_fw_table.c index 7545a29..4519472 100644 --- a/sys/netinet/ipfw/ip_fw_table.c +++ b/sys/netinet/ipfw/ip_fw_table.c @@ -52,6 +52,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include /* ip_fw.h requires IFNAMSIZ */ #include --------------090809000406030208080301-- From owner-freebsd-net@FreeBSD.ORG Wed Jul 18 14:42:52 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id EECEE106566B; Wed, 18 Jul 2012 14:42:51 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from dhcp170-36-red.yandex.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with ESMTP id A9FAC14EA9C; Wed, 18 Jul 2012 14:42:49 +0000 (UTC) Message-ID: <5006CAFC.1000206@FreeBSD.org> Date: Wed, 18 Jul 2012 18:41:00 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120511 Thunderbird/12.0.1 MIME-Version: 1.0 To: Eugene Grosbein References: <4FF36438.2030902@FreeBSD.org> <4FF3E2C4.7050701@FreeBSD.org> <4FF3FB14.8020006@FreeBSD.org> <4FF402D1.4000505@FreeBSD.org> <20120704091241.GA99164@onelab2.iet.unipi.it> <4FF412B9.3000406@FreeBSD.org> <20120704154856.GC3680@onelab2.iet.unipi.it> <4FF59955.5090406@FreeBSD.org> <20120706061126.GA65432@onelab2.iet.unipi.it> <500452A5.3070501@FreeBSD.org> <20120716232352.GE2676@deviant.kiev.zoral.com.ua> <500566F3.9050101@rdtc.ru> In-Reply-To: <500566F3.9050101@rdtc.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Cc: Konstantin Belousov , Doug Barton , Luigi Rizzo , net@freebsd.org Subject: Re: FreeBSD 10G forwarding performance @Intel 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: Wed, 18 Jul 2012 14:42:52 -0000 On 17.07.2012 17:21, Eugene Grosbein wrote: > 17.07.2012 06:23, Konstantin Belousov ΠΙΫΕΤ: > >> I do not think that your 'per-cpu' counter are correct. The thread >> migration or rescheduling causes the fetch or update of the wrong >> per-cpu structure. This allows parallel updates with undefined >> consequences. > >> From practical point of view, I'like to state that most of us do NOT > need scientifically exact ipfw counters values when pushing hardware to its maximum. > > Personaly, I'd like to have tunable that gives me another 15% of speed > at cost of bad ipfw counters I don't use anyway. It seems that this can be done even with sysctl. The same approach can be applied to per-cpu interface counters (and global per-protocol statistics). > > Eugene Grosbein > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- WBR, Alexander From owner-freebsd-net@FreeBSD.ORG Wed Jul 18 17:24:34 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 B22BF106566C for ; Wed, 18 Jul 2012 17:24:34 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3D6E78FC08 for ; Wed, 18 Jul 2012 17:24:34 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so1570996wgb.31 for ; Wed, 18 Jul 2012 10:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BSNTrszUKQ2VvXtt2cAfEZkPjJMEuv+TXF3jN6dg5Qg=; b=i0gyuX0UHAm4RQmWIM1AtXAIcecNaqHxqaRXzOykp1q48ZO9WxkY2L79Gcw1ZiLTP3 Hns7D3NHLU0/BfX0mq2h2aILTu1KFez1i3LpnWuvo9f5vEJ90Ka244Qpwqojh0O2HWtW Ptpeh2Ccrs4US6EiFBcn8IMDdZKuxXhRNWvo0zyAK/N7av1faJuGEZtZK32tj5/v5VHW JkGRINP3LKESUwXi7G3MejHCMPhg5TxdkSuh8xE/zmaqIRj9AosKYgrbDkMZvq6xabmh bWk37JgmImuSyvP3u23OL4d2RBINSffWucjTfXEcX60PXPCFBdszjkCFmTWmLo2lHcrw 4Gfg== MIME-Version: 1.0 Received: by 10.216.133.200 with SMTP id q50mr78235wei.166.1342632273156; Wed, 18 Jul 2012 10:24:33 -0700 (PDT) Received: by 10.216.79.81 with HTTP; Wed, 18 Jul 2012 10:24:33 -0700 (PDT) In-Reply-To: <50065E0E.50903@zonov.org> References: <5003EDC4.3050100@zonov.org> <50048A34.10304@zonov.org> <50065E0E.50903@zonov.org> Date: Wed, 18 Jul 2012 13:24:33 -0400 Message-ID: From: Arnaud Lacombe To: Andrey Zonov Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" Subject: Re: panic: negative refcount 0xfffffe0007f1b4d4 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: Wed, 18 Jul 2012 17:24:34 -0000 Hi, On Wed, Jul 18, 2012 at 2:56 AM, Andrey Zonov wrote: > Index: sys/sys/refcount.h > =================================================================== > --- sys/sys/refcount.h (revision 234600) > +++ sys/sys/refcount.h (working copy) > @@ -51,6 +51,7 @@ static __inline void > refcount_acquire(volatile u_int *count) > { > > + KASSERT(*count < 0xffffff00, ("refcount %p is overflowed", count)); > atomic_add_acq_int(count, 1); > } > > > It will give better diagnostic when refcount is overflowed, instead of > "negative refcount". > this is completely bogus. Why arbitrarily use 0xffffff00, why not 0xdeadbeef or 0xbabeb00b ? 0xfffffffe is a perfectly valid reference count value. The only logical assertion would be to check if the increment is to trigger an overflow of the underlying type used to store the reference count value. That is (*count < 0xffffffff). Moreover, advertising the current value of the counter in the panic message is absolutely useless... - Arnaud From owner-freebsd-net@FreeBSD.ORG Thu Jul 19 02:59:02 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 79F93106564A for ; Thu, 19 Jul 2012 02:59:02 +0000 (UTC) (envelope-from nobody@web1.www.grayloon.com) Received: from web1.www.grayloon.com (138973-web1.www.grayloon.com [67.192.51.163]) by mx1.freebsd.org (Postfix) with ESMTP id 4C7D68FC12 for ; Thu, 19 Jul 2012 02:59:02 +0000 (UTC) Received: from nobody by web1.www.grayloon.com with local (Exim 4.77) (envelope-from ) id 1SrgiP-0001IJ-EO for freebsd-net@freebsd.org; Wed, 18 Jul 2012 21:43:45 -0500 To: freebsd-net@freebsd.org From: instantcashdaily@gmail.co.uk Content-type: text/plain; charset=ISO-8859-1 Message-Id: Date: Wed, 18 Jul 2012 21:43:45 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web1.www.grayloon.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12] X-AntiAbuse: Sender Address Domain - web1.www.grayloon.com Subject: NatGear Camo Fabric 600 Denier Polyester X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: instantcashdaily@gmail.co.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 02:59:02 -0000 Name: Shawn Anderson Email: instantcashdaily@gmail.co.uk Time To Take Your $850 Recurring Commission Now!!! Welcome Friend, Congratulations, Get Your First $850 Commissions Now! Good News, Now You've Earn Weekly Direct To Your Paypal Account. No Need Any Experience,No Big Cash Are Involve,Only by Joining or Sign Up are important this New Program So,Join Now. We've Start putting Members in YOUR TEAM for JULY 13/20/2012 Weekly cycle. YOU ALREADY HAVE 1,888 Pre-Enrollees and 50 PAID Members in your team. Only 3 SPOTS Available remaining before Commission Cycle Ends. IMPORTANT: ORDER NOW Before JULY 18, 2012 is the Cut-Off date To lock in your Commission! For Only $17 Lifetime Membership To secure your GUARANTEED $850 Commission You Get-Paid direct to your PAYPAL Now this Coming JULY 31, 2012. Be sure to ORDER NOW to secure your GUARANTEED $850 Commission Now! http://payspree.com/6434/dollar2012 Hurry 3 remaining Copies before Close TYPE - Date and Time -- New PAID Members -- Country P JULY 15 @ 04:21 PM = David Holme ===== United States P JULY 15 @ 04:21 PM == Steve Jones ===== United States P JULY 15 @ 06:37 AM === Cole Baker ===== United Kingdom P JULY 16 @ 08:21 PM ==== Jane Parker ===== germany P JULY 16 @ 04:21 PM ===== Eliza Rose ===== Portugal P JULY 16 @ 06:37 AM ====== David Cole ===== United Kingdom P JULY 16 @ 08:21 PM ======= Jake Archel ===== canada P JULY 16 @ 01:38 PM ======== Davis Ganz ===== Sri Lanka P JULY 16 @ 04:15 AM ========= KiethDalton ===== United Kingdom P JULY 16 @ 02:45 PM ========== Steve Kalde ===== United States P JULY 16 @ 11:15 AM =========== Kath Casey ===== United Kingdom P JULY 16 @ 11:15 AM =========== Jaime Palma ===== Canada P JULY 16 @ 01:45 AM ========== Jimmy Sasai ===== United States P JULY 16 @ 11:50 PM ========= Anne Salde ===== Sri Lanka P JULY 16 @ 02:45 AM ======== Timmy Brown ===== United States P JULY 16 @ 05:59 AM ======= Victor Ches ===== Italy P JULY 16 @ 11:32 PM ====== Gaynell Sou ===== South Africa P JULY 16 @ 09:40 AM ===== Barba Tart ===== Portugal P JULY 16 @ 01:21 AM ==== James Andis ===== North Carolina P JULY 16 @ 09:40 AM === Boby Vinton ===== Portugal P JULY 16 @ 01:21 AM == Dave Moore ===== North Carolina P JULY 16 @ 01:21 AM = Anie Garet ===== North Carolina Therefore, you have a GUARANTEED $850 Commission every Day! from now on!. Earn $17 Per Process Each $17 x 50 = $850 Commission will be yours....! You must ORDER NOW right away or before JULY 20, 2012 @ 11:59 PM (Pacific Time)---- or you will forever forfeit the $850 Commission that is now yours for the taking. Get-Paid Direct PAYPAL Now this JULY 31, 2012. Be sure to ORDER NOW to secure your GUARANTEED $850 Commission Now! http://payspree.com/6434/dollar2012 Please do realize that if you dont ORDER NOW, ALL Commission that are currently is yours to take. As soon as I receive the confirmation of your Registration, I will be in touch with you to help you get started. To Your Success,Shawn Anderson Affiliate Manager P.S. Early Join This Monthly Contest Are Qualified Member Recieved the $10,000 monthly Commissions. http://www.huntersdesignblinds.com/store/cart.php?m=product_detail&p=35 From owner-freebsd-net@FreeBSD.ORG Thu Jul 19 15:21:49 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 0FE1D1065674 for ; Thu, 19 Jul 2012 15:21:49 +0000 (UTC) (envelope-from help-nr500@aa.com) Received: from mx-n05.wc1.ord1.stabletransit.com (mx-n05.wc1.ord1.stabletransit.com [50.57.219.122]) by mx1.freebsd.org (Postfix) with ESMTP id C1BD78FC19 for ; Thu, 19 Jul 2012 15:21:48 +0000 (UTC) Received: by mx-n05.wc1.ord1.stabletransit.com (Postfix, from userid 99) id 25B1B1573759; Thu, 19 Jul 2012 09:56:30 -0500 (CDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mx-n05.wc1.ord1.stabletransit.com X-Spam-Level: * X-Spam-Status: No, score=1.1 required=6.0 tests=HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=3.3.1 Received: from mx-n05.wc1.ord1.stabletransit.com (localhost.localdomain [127.0.0.1]) by mx-n05.wc1.ord1.stabletransit.com (Postfix) with ESMTP id 68F2C157374E for ; Thu, 19 Jul 2012 09:56:21 -0500 (CDT) Received: by mx-n05.wc1.ord1.stabletransit.com (Postfix, from userid 300) id 672681588105; Thu, 19 Jul 2012 09:56:21 -0500 (CDT) Received: from php5-v48.wc1.ord1.stabletransit.com (unknown [10.187.244.22]) by mx-n05.wc1.ord1.stabletransit.com (Postfix) with ESMTP id 57E371588106 for ; Thu, 19 Jul 2012 09:56:21 -0500 (CDT) Received: by php5-v48.wc1.ord1.stabletransit.com (Postfix, from userid 28915) id 51D3E968375; Thu, 19 Jul 2012 09:56:21 -0500 (CDT) To: freebsd-net@freebsd.org X-PHP-Script: retiregfw.com/.d03c.php for 127.0.0.1 From: "American Airlines" X-Mailer: UnityMail Mime-Version: 1.0 Content-Type: multipart/mixed;boundary="----------1342709781500820154E1AC" Message-Id: <20120719145621.51D3E968375@php5-v48.wc1.ord1.stabletransit.com> Date: Thu, 19 Jul 2012 09:56:21 -0500 (CDT) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Your order # NR17-6017 has been completed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: American Airlines List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 15:21:49 -0000 ------------1342709781500820154E1AC Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain; This throng of villages continues through all the east part of the country, which is of the greatest extent, and where the manufacture is chiefly carried on.If any part of it be waste and thin of inhabitants, it is the west part, drawing a line from about Brand, or Brandon, south, to Walsinghan, north. This part of the country indeed is full of open plains, and somewhat sandy and barren, and feeds great flocks of good sheep; but put it all together, the county of Norfolk has the most people in the least tract of land of any county in England, except about London, and Exon, and the West Riding of Yorkshire, as above. Add to this, that there is no single county in England, except as above, that can boast of three towns so populous, so rich, and so famous for trade and navigation, as in this county. By these three towns, I mean the city of Norwich, the towns of Yarmouth and Lynn. Besides that, it has several other seaports of very good trade , as Wisbech, Wells, Burnham, Clye, etc. My family cast off me and all my works many years ago, but I put my pride in my pocket and appealed for help for Gillian and they suggested--a damned charitable institution!I was pretty nearly desperate until I thought of you. I know no one else. For Gods sake, Barry, dont fail me. I can and I do trust Gillian to you. I have made you her guardian, it is all legally arranged and my lawyer in London has the papers. He is a well-known man and emanates respectability--my last claim to decency! Gillian is at the Convent of the Sacred Heart in Paris. My only consolation is that you are so rich that financially she will be no embarrassment to you. I realize what I am asking and the enormity of it, but I am a dying man and my excuse is--Gillian. Oh, man, be good to my little girl. I always hoped that something would turn up, but it didnt! Perhaps I never went to look for it, _quien sabe _ I shall never have the chance again.... On hearing this, the potter thought, Well, this is evidently not a bh"t, but the voice of an ordinary man.Ill cut the flesh carefully. May be that I shall find some poor distressed person. So he began to cut away the flesh carefully, and presently he perceived a mans foot, then the legs appeared, and then the entire body. Praise be to God, he cried, the soul is yet in him. He carried the man to his house as fast as he could, and on arriving there did everything in his power to recover him. A large fire was soon got ready, and tea and soup given the man, and great was the joy of the potter and his wife when they saw him reviving. [FN#514] For some months the stranger lived with those good people, and learnt how to make pots and pans and other articles and thereby helped them considerably. Now it happened that the king of that country died and it was the custom of the people to take for their sovereign whomsoever the late kings elepha nt and hawk should select. References Visible links Hidden links: 1. http://www.arxsolutions.com/PGBRGEOBRR.htm ------------1342709781500820154E1AC-- From owner-freebsd-net@FreeBSD.ORG Thu Jul 19 18:29:18 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 166D71065672; Thu, 19 Jul 2012 18:29:18 +0000 (UTC) (envelope-from kickbsd@yandex.com) Received: from forward10.mail.yandex.net (forward10.mail.yandex.net [IPv6:2a02:6b8:0:202::5]) by mx1.freebsd.org (Postfix) with ESMTP id 1801B8FC0A; Thu, 19 Jul 2012 18:29:16 +0000 (UTC) Received: from web2e.yandex.ru (web2e.yandex.ru [77.88.60.146]) by forward10.mail.yandex.net (Yandex) with ESMTP id 5BC9E102062E; Thu, 19 Jul 2012 22:29:15 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1342722555; bh=3AccS/RbhftmFxU7SaoNBPlUILqMw7YYs46AECcxkoM=; h=From:To:Cc:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=tvn7BcXbb3aNtdWGEEiJQ0kfdwnw5FhBYGb+MDG18VJuxMZV7vT831rBIQJsTQDJ5 QT/fVEJj6eQPD6pgX0U4RwFlC29VOsQnKn0KeHzcVGQfFRdUPvntscDj//Ile+m/X0 2cReADgNdaJfAVMTdXMRUCiVOzJdWOkyNejfJbLM= Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by web2e.yandex.ru (Yandex) with ESMTP id BF8AC660048; Thu, 19 Jul 2012 22:29:14 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1342722555; bh=3AccS/RbhftmFxU7SaoNBPlUILqMw7YYs46AECcxkoM=; h=From:To:Cc:In-Reply-To:References:Subject:Date; b=cE35uNbPlBChkaSrmkXlpaESsMyxW6h9fnG+ILWY8rxlJu/F/hgxMV5BjJJg5fsBi r6wFXryKWqap2IkvGzP2w/yljLvEeLBoKVLAPvBTwrqDXj3CXchKxp/9SDfty9dXOC GufpFOdeymZbrqcAabdvYC+/28cuVHfjb6g49BiA= Received: from leo.de.teleglobe.net (leo.de.teleglobe.net [64.86.53.146]) by web2e.yandex.ru with HTTP; Thu, 19 Jul 2012 22:29:13 +0400 From: Darren Baginski To: Mike Tancsa In-Reply-To: <671621333467557@web119.yandex.ru> References: <167651329324260@web72.yandex.ru> <316881329935015@web67.yandex.ru> <4F453A06.9060101@sentex.net> <637271333462764@web119.yandex.ru> <4F7B0886.70200@sentex.net> <671621333467557@web119.yandex.ru> MIME-Version: 1.0 Message-Id: <840431342722553@web2e.yandex.ru> Date: Thu, 19 Jul 2012 22:29:13 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r Cc: "freebsd-net@freebsd.org" , Adrian Chadd , Jack Vogel Subject: Re: IGB freezes after about 2 weeks of uptime 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: Thu, 19 Jul 2012 18:29:18 -0000 Hi! Issue still exists in today's CVSUP code # uname -a FreeBSD srv-4-2.lab.local 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #13: Thu Jul 19 17:55:00 UTC 2012 root@srv-4-2.lab.local:/usr/obj/usr/src/sys/GENERIC amd64 igb0: link state changed to UP igb1: link state changed to UP igb1: Watchdog timeout -- resetting igb1: Queue(0) tdh = 0, hw tdt = 1 igb1: TX(0) desc avail = 0,Next TX to Clean = 3 igb1: link state changed to DOWN igb1: link state changed to UP igb0: Watchdog timeout -- resetting igb0: Queue(0) tdh = 160, hw tdt = 173 igb0: TX(0) desc avail = 0,Next TX to Clean = 0 igb0: link state changed to DOWN igb0: link state changed to UP 8.2-RELEASE-p9 is unaffected on the same box. >> šHi, >> šššššššššTry the driver from HEAD. It has a number of fixes in it to both the >> šigb and em drivers that is not yet in RELENG_9 nor 8 >> >> šhttp://lists.freebsd.org/pipermail/svn-src-head/2012-March/035888.html >> >> ššššššššš---Mike >> >> šOn 4/3/2012 10:19 AM, Darren Baginski wrote: >>> ššStill getting same errors on >>> šššFreeBSD srv-4-2.lab.local 9.0-STABLE FreeBSD 9.0-STABLE #3: Mon Apr š2 >>> šš19:07:20 UTC 2012 >>> ššroot@srv-4-2.lab.local:/usr/obj/usr/src/sys/GENERIC šamd64 >>> ššIt's only me or it's known problem ? >>> >>> šš22.02.2012, 23:46, "Jack Vogel" : >>>> ššMike is correct, 8.3 was looming, it is important to a lot of my >>>> ššcustomers so it >>>> ššhas taken priority, 9 stable will be coming... >>>> >>>> ššJack >>>> >>>> ššOn Wed, Feb 22, 2012 at 10:55 AM, Mike Tancsa >>> šš> wrote: >>>> >>>> ššššššI dont think the driver changes from HEAD were ever MFC'd to 9.x. >>>> šššššššOnly >>>> ššššššto 8.x >>>> >>>> ššššššššššššš---Mike >>>> >>>> ššššššOn 2/22/2012 1:23 PM, Darren Baginski wrote: >>>>> ššSame problem on >>>>> ššFreeBSD srv-4-2.lab.local 9.0-STABLE FreeBSD 9.0-STABLE #2: Wed >>>> ššššššFeb 22 18:10:53 UTC 2012 ššššroot@srv-4-2.lab.local >>>> šššššš:/usr/obj/usr/src/sys/GENERIC šamd64 >>>>> šš16.02.2012, 02:27, "Jack Vogel" >>> šššššš>: >>>>>> ššAnd assuming its from the release, please upgrade it to HEAD >>>> ššššššand try again. >>>>>> ššJack >>>>>> >>>>>> ššOn Wed, Feb 15, 2012 at 2:14 PM, Adrian Chadd >>>> šššššš> wrote: >>>>>>> ššare you running the driver from that release, or the -HEAD driver? >>>>>>> >>>>>>> ššadrian From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 00:59:40 2012 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 04BF7106564A for ; Fri, 20 Jul 2012 00:59:40 +0000 (UTC) (envelope-from prabhakar.lakhera@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7C75B8FC08 for ; Fri, 20 Jul 2012 00:59:39 +0000 (UTC) Received: by lbon10 with SMTP id n10so5469607lbo.13 for ; Thu, 19 Jul 2012 17:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=viLUhLc4J4XkIDZe1bWRfxRVSbDXXToF2wz7Fesl6/Y=; b=Hh52tZIxsLg4N7qRt7yuIEGoe6lUtXU2I/RzQm7rqyMbCTmAK8hgEjPvfYcjwOlOL+ D0Pi0Ht7SNuY73M3XpD3XGPQvDDl2Gv7ChFp5GaGrzdHM7A3hKjTO6hXz9F63y2dzMzX cUmt/gQJrBqMGSY7cdVNif/5twRd26zrWgZE/R5WDfFcQ+L3eSS1gOxfWHs5PTur7ZR9 O0Eo1V09kS6z3Bmp3/Hb6N6QLtbXYyF0jWJYdrO+wQbOtg4c14wGzHgvqd+5YyjP0NXE cmv8H+sern2OpHB2IRBr8ZTCBx+E3/B4y9NSIkWGn8q/E7O6Rs0JEy0s10mzABaGvv2B 8OBQ== MIME-Version: 1.0 Received: by 10.152.104.44 with SMTP id gb12mr4174228lab.29.1342745978452; Thu, 19 Jul 2012 17:59:38 -0700 (PDT) Received: by 10.114.23.170 with HTTP; Thu, 19 Jul 2012 17:59:38 -0700 (PDT) Date: Thu, 19 Jul 2012 17:59:38 -0700 Message-ID: From: prabhakar lakhera To: freebsd-net@freebsd.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: defrouter_addreq calling RTFREE? 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: Fri, 20 Jul 2012 00:59:40 -0000 Hi, It could very well be that my brain wires are not working late in the day. >From what I know most of the routing table entries (unless referenced by some other entity or another route in routing table) have reference count 0. At least that's how things used to be in BSD as also stated in TCP IP illustrated: *Routing Table Reference Counts* *The handling of the routing table reference count, rt_refcnt, differs from most other reference * *counts. We see in Figure 18.2 that most routes have a reference count of 0, yet the routing table entries * *without any references are not deleted. We just saw the reason in rtfree: an entry with a * *reference count of 0 is not deleted unless the entry=92s RTF_UP flag is no= t set. The only time this flag * *is cleared is by rtrequest when a route is deleted from the routing tree. = * I fail to understand why defrouter_addreq in nd6_rtr.c calls RTFREE: error =3D rtrequest(RTM_ADD, (struct sockaddr *)&def, (struct sockaddr *)&gate, (struct sockaddr *)&mask, RTF_GATEWAY, &newrt); =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> Since we provide &newr= t the reference would be incremented to 1? if (newrt) { nd6_rtmsg(RTM_ADD, newrt); /* tell user process */ RTFREE(newrt); =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> When we call= RTFREE the reference is 1? } Now RTFREE has been defined as: #define RTFREE(_rt) do { \ RT_LOCK(_rt); \ RTFREE_LOCKED(_rt); \ } while (0) and RTFREE_LOCKED is defined as: #define RTFREE_LOCKED(_rt) do { \ if ((_rt)->rt_refcnt <=3D 1) \ rtfree(_rt); \ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> rtfre= e will be called since ref else { \ RT_REMREF(_rt); \ RT_UNLOCK(_rt); \ } \ /* guard against invalid refs */ \ _rt =3D 0; \ } while (0) Shouldn't the count be just decremented calling RT_REMREF(rt); like in rtinit? Best, Prabhakar From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 01:02:08 2012 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 4DDD5106566C for ; Fri, 20 Jul 2012 01:02:08 +0000 (UTC) (envelope-from prabhakar.lakhera@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id BDDC28FC14 for ; Fri, 20 Jul 2012 01:02:07 +0000 (UTC) Received: by lbon10 with SMTP id n10so5472221lbo.13 for ; Thu, 19 Jul 2012 18:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=h97YnohDV8vuDLA0yrt9GQ4ZuJuFZ/aaEQsrgk9qX+c=; b=HkmPJ+8cTzJP9SGTRTdlSAMsFyxRMdeIwzgeII01axZ9oI+lSH65wV+V9hB+bkvM2s Man8xCfz7mVaoAAlkOoaC8tQrraZt1m6GkOf/mvyU/46Prsgrao3pH4P2Mc0ncB/9aEX UXLGs+SoYfTEmq04aenItnJMrB1h+JOt8JQPnW5kRzUvi6/4RRF5WgGsiYOApsOo74k3 JNeW95ud2IB2TVsZE5LmfTzKywFi646vHg4oz4smI2+qG4h1Tpx4V70qE+oWEGpOrYWr GftpocMlyzduOeEVA2heS6gh5peWgpYnqEIOmK+Op9jsQj6tTXeZo/3A802tDrCc8YI8 4XRw== MIME-Version: 1.0 Received: by 10.112.86.105 with SMTP id o9mr2087186lbz.32.1342746126714; Thu, 19 Jul 2012 18:02:06 -0700 (PDT) Received: by 10.114.23.170 with HTTP; Thu, 19 Jul 2012 18:02:06 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Jul 2012 18:02:06 -0700 Message-ID: From: prabhakar lakhera To: freebsd-net@freebsd.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: defrouter_addreq calling RTFREE? 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: Fri, 20 Jul 2012 01:02:08 -0000 I see that it changed from 7 to 8. However doesn't specify why. Have some semantics changed? On Thu, Jul 19, 2012 at 5:59 PM, prabhakar lakhera < prabhakar.lakhera@gmail.com> wrote: > Hi, > > It could very well be that my brain wires are not working late in the day= . > From what I know most of the routing table entries (unless referenced by > some other entity or another route in routing table) have reference count > 0. At least that's how things used to be in BSD as also stated in TCP IP > illustrated: > > *Routing Table Reference Counts* > *The handling of the routing table reference count, rt_refcnt, differs > from most other reference * > *counts. We see in Figure 18.2 that most routes have a reference count of > 0, yet the routing table entries * > *without any references are not deleted. We just saw the reason in > rtfree: an entry with a * > *reference count of 0 is not deleted unless the entry=92s RTF_UP flag is > not set. The only time this flag * > *is cleared is by rtrequest when a route is deleted from the routing > tree. * > > I fail to understand why defrouter_addreq in nd6_rtr.c calls RTFREE: > > error =3D rtrequest(RTM_ADD, (struct sockaddr *)&def, > (struct sockaddr *)&gate, (struct sockaddr *)&mask, > RTF_GATEWAY, &newrt); > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> Since we provide &= newrt the reference would be > incremented to 1? > if (newrt) { > nd6_rtmsg(RTM_ADD, newrt); /* tell user process */ > RTFREE(newrt); > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> When we ca= ll RTFREE the reference is 1? > } > > Now RTFREE has been defined as: > > #define RTFREE(_rt) do { \ > RT_LOCK(_rt); \ > RTFREE_LOCKED(_rt); \ > } while (0) > > and RTFREE_LOCKED is defined as: > > #define RTFREE_LOCKED(_rt) do { \ > if ((_rt)->rt_refcnt <=3D 1) \ > rtfree(_rt); \ > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> r= tfree will be called since ref > else { \ > RT_REMREF(_rt); \ > RT_UNLOCK(_rt); \ > } \ > /* guard against invalid refs */ \ > _rt =3D 0; \ > } while (0) > > > Shouldn't the count be just decremented calling RT_REMREF(rt); like in > rtinit? > > Best, > > Prabhakar > > > > From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 10:32:29 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 9CE7E106566B for ; Fri, 20 Jul 2012 10:32:29 +0000 (UTC) (envelope-from venkatduvvuru.ml@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 59CB28FC08 for ; Fri, 20 Jul 2012 10:32:29 +0000 (UTC) Received: by ggnm2 with SMTP id m2so4490148ggn.13 for ; Fri, 20 Jul 2012 03:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=m4Tm4nMW/ySzTXmWRAktslTzSoNptgEx/La6nA+JNro=; b=ALGEj8mYCJOqzpXkFAi4S2MS5vp4UWB9hNuIbBr7+NrUpolpWGjtsgaOJw8nFF0MKv S0ILdyMGIq3TZgJh9oRcug7GjI6wzFCH7WFn8usgCbCLuA1JqDt0cgdk34GwmDxNxP8m P/PL+GbDmanlxu3efwZu3kf0uuXVwOP6cFd3vkDmXFn2n04TlShbFjAtqU8bIQVas92H 5mIj7bgwYeIMj8X3kPhV3uYZbdgprO+ysIaL2RM46fdTPr4+lB4HGqmT2nC+gM4gLeT6 2e3VbU29magiJZOZhyb9UTLSNWtr9TM+ThSl2gGnMfdsdvvEUP0oSgjUWa6OZjBYCfYb GIjA== MIME-Version: 1.0 Received: by 10.50.184.198 with SMTP id ew6mr4048988igc.27.1342780348451; Fri, 20 Jul 2012 03:32:28 -0700 (PDT) Received: by 10.64.106.202 with HTTP; Fri, 20 Jul 2012 03:32:28 -0700 (PDT) Date: Fri, 20 Jul 2012 16:02:28 +0530 Message-ID: From: Venkat Duvvuru To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: AF_LINK problem 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: Fri, 20 Jul 2012 10:32:29 -0000 Hi, I'm trying to create a socket under AF_LINK family but freebsd is saying that "protocol is not supported" while creating the socket. Is AF_LINK not supported? /Venkat From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 11:54:53 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 D29F3106566B for ; Fri, 20 Jul 2012 11:54:53 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6AAA68FC0A for ; Fri, 20 Jul 2012 11:54:52 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=dhcp170-36-red.yandex.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1SsBpy-000DVb-6J; Fri, 20 Jul 2012 15:57:38 +0400 Message-ID: <50094698.3000407@ipfw.ru> Date: Fri, 20 Jul 2012 15:52:56 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120627 Thunderbird/13.0.1 MIME-Version: 1.0 To: Venkat Duvvuru References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: AF_LINK problem 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: Fri, 20 Jul 2012 11:54:53 -0000 On 20.07.2012 14:32, Venkat Duvvuru wrote: > Hi, > I'm trying to create a socket under AF_LINK family but freebsd is saying > that "protocol is not supported" while creating the socket. > Is AF_LINK not supported? If you're doing this to send raw ethernet frames you have to use bpf(4) instead. > > /Venkat > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- WBR, Alexander From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 13:21:47 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 DFF1E1065670 for ; Fri, 20 Jul 2012 13:21:46 +0000 (UTC) (envelope-from venkatduvvuru.ml@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 980AD8FC14 for ; Fri, 20 Jul 2012 13:21:46 +0000 (UTC) Received: by ggnm2 with SMTP id m2so4665510ggn.13 for ; Fri, 20 Jul 2012 06:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YuiIDybNRjM9SNHJw81g613vzTZyKdrNAbrOVZ5j8oY=; b=OhigH6dKDw7KXHxdpEzqFCk6d5X3qD3A1BuRaq6nmB95fRoU1MVwntcvjco5CB50N9 +qrjkUinS9tDIxFSW3ILZFlEnxyBADjcLoz1pcFH3QN8l+ygz/l29jrC1hq1ZKbVQqvD C4uzU1anpSo1mt2VZwssUv/5WRJJBe+QlmPVppjsAlTmE4EY33p8cwH6oSAG3znAgSK9 L/RiwEvwj2aRWqrQ5pIeTVlNcVZVaEMMVIBE4+rMca8kr8hzjN0rqyqJUc5PExPVm0wf vw370aiDx4EdQkhCY8OBsWk6ZrtEnkGeSH/k8qmtEBMg4dGBf+BJ/YBBo4+GUcGmUMY2 5EFg== MIME-Version: 1.0 Received: by 10.50.184.198 with SMTP id ew6mr4464759igc.27.1342790506039; Fri, 20 Jul 2012 06:21:46 -0700 (PDT) Received: by 10.64.106.202 with HTTP; Fri, 20 Jul 2012 06:21:46 -0700 (PDT) In-Reply-To: <50094698.3000407@ipfw.ru> References: <50094698.3000407@ipfw.ru> Date: Fri, 20 Jul 2012 18:51:46 +0530 Message-ID: From: Venkat Duvvuru To: "Alexander V. Chernikov" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: AF_LINK problem 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: Fri, 20 Jul 2012 13:21:47 -0000 Thanks Alexandar! That's what I'm looking for! /Venkat On Fri, Jul 20, 2012 at 5:22 PM, Alexander V. Chernikov wrote: > On 20.07.2012 14:32, Venkat Duvvuru wrote: > >> Hi, >> I'm trying to create a socket under AF_LINK family but freebsd is saying >> that "protocol is not supported" while creating the socket. >> Is AF_LINK not supported? >> > If you're doing this to send raw ethernet frames you have to use bpf(4) > instead. > >> >> /Venkat >> ______________________________**_________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/**mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@**freebsd.org >> " >> >> > > -- > WBR, Alexander > > > From owner-freebsd-net@FreeBSD.ORG Sat Jul 21 05:50:26 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F36F1106566B; Sat, 21 Jul 2012 05:50:25 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C73148FC0A; Sat, 21 Jul 2012 05:50:25 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6L5oPnR006846; Sat, 21 Jul 2012 05:50:25 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6L5oP65006842; Sat, 21 Jul 2012 05:50:25 GMT (envelope-from linimon) Date: Sat, 21 Jul 2012 05:50:25 GMT Message-Id: <201207210550.q6L5oP65006842@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/169991: [if_run] [vimage] panic after device plugged in 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: Sat, 21 Jul 2012 05:50:26 -0000 Synopsis: [if_run] [vimage] panic after device plugged in Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Jul 21 05:50:09 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=169991