From owner-freebsd-net@FreeBSD.ORG Sun Apr 22 02:14:56 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 05F45106564A; Sun, 22 Apr 2012 02:14:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id B45D58FC0A; Sun, 22 Apr 2012 02:14:55 +0000 (UTC) Received: by dadz14 with SMTP id z14so45617038dad.17 for ; Sat, 21 Apr 2012 19:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=HT2oWPz3LCzviZQj+UMqkqe4/UInhbXNcKbU1f06fBQ=; b=CPUshxn2alMC7pd+VKHDUzmvrL9gXa4SXOz32X6nAsuhTbAqUs5OuWSFO0B6OlIT5U Bn/mFbQ3U/H9yBWgX6+EsKTkQGH5egVDYdthATvO7bsFu/39Z4RuTCZ447ylZn72Txib PnU5ubVYXK/SzPmIHh8ZVUR/8+I20xfeF4Zoxu4BLkQzg5fi8MwET+nvPY4XDSJMYfN0 czX+LGf2c4fbw9NyitFznyBhmUkl4D9dzc0zLMOlY9P719zN4XNs87B/pxEwUlAv+nSY iqekPMRhDzSM0Are3rqT+AbOoJr6sWwMkOOapP4ghIPmCgVy3vPEHJKnvFWFaQiNQkIM 0Lag== MIME-Version: 1.0 Received: by 10.68.229.33 with SMTP id sn1mr25189039pbc.59.1335060895158; Sat, 21 Apr 2012 19:14:55 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.142.101.9 with HTTP; Sat, 21 Apr 2012 19:14:54 -0700 (PDT) In-Reply-To: <20120421155638.E982@besplex.bde.org> References: <20120419133018.GA91364@onelab2.iet.unipi.it> <4F907011.9080602@freebsd.org> <20120419204622.GA94904@onelab2.iet.unipi.it> <20120419212224.GA95459@onelab2.iet.unipi.it> <20120420144410.GA3629@onelab2.iet.unipi.it> <20120421155638.E982@besplex.bde.org> Date: Sat, 21 Apr 2012 19:14:54 -0700 X-Google-Sender-Auth: TpLJaMqNtGbNhPK9AUpmPxb9mhg Message-ID: From: Adrian Chadd To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Cc: Luigi Rizzo , net@freebsd.org, Andre Oppermann , "K. Macy" , current@freebsd.org Subject: Re: Some performance measurements on the FreeBSD network stack 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, 22 Apr 2012 02:14:56 -0000 Hi, This honestly sounds like it's begging for an instrumentation/analysis/optimisation project. What do we need to do? Adrian From owner-freebsd-net@FreeBSD.ORG Sun Apr 22 05:22:25 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 C97F9106564A for ; Sun, 22 Apr 2012 05:22:25 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 5F4FE8FC0C for ; Sun, 22 Apr 2012 05:22:25 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q3M5MHCd093341 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 21 Apr 2012 22:22:19 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4F939583.9020408@freebsd.org> Date: Sat, 21 Apr 2012 22:22:11 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Barney Cordoba References: <1335008989.85136.YahooMailClassic@web126004.mail.ne1.yahoo.com> In-Reply-To: <1335008989.85136.YahooMailClassic@web126004.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 7 on Newer MBs 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, 22 Apr 2012 05:22:25 -0000 On 4/21/12 4:49 AM, Barney Cordoba wrote: > For a variety of reasons I have a client stuck on FreeBSD 7.0 and they're interested in getting a MB that uses the latest CPUS. They're just using the console, so there are no graphics; can someone provide insight as to whether this would be expected to work without serious problems? "should" but I'd find one somewhere and try a thumb drive out on it. 7.0 is not so far in the past that there has been any big architectural change that affects the kernel. some drivers may not run in the most optimal way. (some sata stuff for example) bit it should run. > BC > _______________________________________________ > 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 Sun Apr 22 05:51:37 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 CC4BE106566C; Sun, 22 Apr 2012 05:51:37 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 981D08FC0C; Sun, 22 Apr 2012 05:51:37 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so2641647pbc.13 for ; Sat, 21 Apr 2012 22:51:37 -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=lr2CVhvlGL8nBa5sUEvfngYjOwACXVh4VfsaKRRskSg=; b=q1Wmb2g6BLMUQ6bgcphQfHTIx/dq2d1gD0QYqOiFg0BAjbGq/cbYTN5VrhUfZ8WQ97 tYBMWJAXfEeuUnMIQuzvlB2MP+50MscnySxrPPmFFq1XSTLLfxNFU5PLBAKWfmJsfdEu JJr+KoeC+5rcGOF4Up6CWvzpFXq4SNND9RVqt6PychOzH6BSrhwb40wXmXDpavaygk2X 911lFBISdfrU0bGFUqrIzc5FkjpvF+krpiDZFi+/h/zBZAfKVW95G2IcLUhy34ntzgm+ +M5G/uncx/UfH0ySxtd//DbzhuzTjRJo30jWkNOCLR/ut8yPkRhQHKXLHwTHA/SEKF49 2RPQ== MIME-Version: 1.0 Received: by 10.68.75.45 with SMTP id z13mr25639228pbv.100.1335073897193; Sat, 21 Apr 2012 22:51:37 -0700 (PDT) Received: by 10.143.18.11 with HTTP; Sat, 21 Apr 2012 22:51:37 -0700 (PDT) In-Reply-To: References: <1334705064.4486.23.camel@powernoodle-l7.corp.yahoo.com> <1334767746.3466.6.camel@powernoodle-l7.corp.yahoo.com> <1334792417.19343.11.camel@powernoodle-l7.corp.yahoo.com> <201204190822.31010.jhb@freebsd.org> Date: Sat, 21 Apr 2012 22:51:37 -0700 Message-ID: From: Vijay Singh To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Luigi Rizzo , Sean Bruno , John Baldwin Subject: Re: igb(4) Raising IGB_MAX_TXD ?? 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, 22 Apr 2012 05:51:37 -0000 >> FWIW, at my current employer we run with both rxd and txd cranked up to 32k >> (we had to patch the driver as you suggested) and have not had any problems >> doing that for a couple of years now. John et al, is this limit specific to igb, or is it applicable to the ixgbe as well. From the 8.x driver code I see: 100/* 101 * TxDescriptors Valid Range: 64-4096 Default Value: 256 This value is the 102 * number of transmit descriptors allocated by the driver. Increasing this 103 * value allows the driver to queue more transmits. Each descriptor is 16 104 * bytes. Performance tests have show the 2K value to be optimal for top 105 * performance. 106 */ 107#define DEFAULT_TXD 1024 108#define PERFORM_TXD 2048 109#define MAX_TXD 4096 110#define MIN_TXD 64 Can the igxbe be extended beyond 4k transmit descriptors well? -vijay From owner-freebsd-net@FreeBSD.ORG Sun Apr 22 06:49:51 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 889DD106566B; Sun, 22 Apr 2012 06:49:51 +0000 (UTC) (envelope-from jfvogel@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 E185A8FC12; Sun, 22 Apr 2012 06:49:50 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so10460572wgb.31 for ; Sat, 21 Apr 2012 23:49:49 -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=aK7I9qsF7plYeSgXVJu2JrvGH1CggK9wXmcljdDXklw=; b=eYKhnAlc7yhyNj5G5CUG4iIrfLDa4wHZrcM+a0VbNIo0GLGgfFepoDnhVliGzF1RKT eDsXR8DTboOTRzh/4AwR9M3WoDwVk58effTcHzxOHPEejFWqtZJ/7G1tcUq+ICrDrT6j S1mgZZpJ+sOzJcPQQ89drD5FBRI/ZDT+Al8+6FtN+C0OBN8+JVK6nXD5OtWT4wBOSlId fVPPO8s8Xl+OpGovX1qpP8pv+fy2z64yw5VUNm3W2Cka51LjGg/M5zU6MXYWuZjsZqaq 6NAMS+kXPbcB+VMtha5mXEw1+zHYSX9JKQSTxu+7Dy8gI4k0U2OLJDN95TH5AcS64oGt 4Zgw== MIME-Version: 1.0 Received: by 10.180.83.198 with SMTP id s6mr11170526wiy.8.1335077389836; Sat, 21 Apr 2012 23:49:49 -0700 (PDT) Received: by 10.180.3.170 with HTTP; Sat, 21 Apr 2012 23:49:49 -0700 (PDT) In-Reply-To: References: <1334705064.4486.23.camel@powernoodle-l7.corp.yahoo.com> <1334767746.3466.6.camel@powernoodle-l7.corp.yahoo.com> <1334792417.19343.11.camel@powernoodle-l7.corp.yahoo.com> <201204190822.31010.jhb@freebsd.org> Date: Sat, 21 Apr 2012 23:49:49 -0700 Message-ID: From: Jack Vogel To: Vijay Singh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Luigi Rizzo , Sean Bruno , John Baldwin Subject: Re: igb(4) Raising IGB_MAX_TXD ?? 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, 22 Apr 2012 06:49:51 -0000 Yes, I'm not sure what the actual hard limit is, will check that on Monday, but you can go over 4K, it was just a limit I created. Jack On Sat, Apr 21, 2012 at 10:51 PM, Vijay Singh wrote: > >> FWIW, at my current employer we run with both rxd and txd cranked up to > 32k > >> (we had to patch the driver as you suggested) and have not had any > problems > >> doing that for a couple of years now. > > John et al, is this limit specific to igb, or is it applicable to the > ixgbe as well. From the 8.x driver code I see: > > 100/* > 101 * TxDescriptors Valid Range: 64-4096 Default Value: 256 This value is > the > 102 * number of transmit descriptors allocated by the driver. Increasing > this > 103 * value allows the driver to queue more transmits. Each descriptor is > 16 > 104 * bytes. Performance tests have show the 2K value to be optimal for top > 105 * performance. > 106 */ > 107#define DEFAULT_TXD 1024 > 108#define PERFORM_TXD 2048 > 109#define MAX_TXD 4096 > 110#define MIN_TXD 64 > > Can the igxbe be extended beyond 4k transmit descriptors well? > > -vijay > From owner-freebsd-net@FreeBSD.ORG Sun Apr 22 13:43:08 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 0A0031065670; Sun, 22 Apr 2012 13:43:08 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D19F68FC16; Sun, 22 Apr 2012 13:43:07 +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 q3MDh7RO018030; Sun, 22 Apr 2012 13:43:07 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3MDh74V018026; Sun, 22 Apr 2012 13:43:07 GMT (envelope-from remko) Date: Sun, 22 Apr 2012 13:43:07 GMT Message-Id: <201204221343.q3MDh74V018026@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/167202: [igmp]: Sending multiple IGMP packets crashes kernel 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, 22 Apr 2012 13:43:08 -0000 Old Synopsis: Sending multiple IGMP packets crashes kernel New Synopsis: [igmp]: Sending multiple IGMP packets crashes kernel Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Sun Apr 22 13:42:43 UTC 2012 Responsible-Changed-Why: Reasisgn to -net. http://www.freebsd.org/cgi/query-pr.cgi?pr=167202 From owner-freebsd-net@FreeBSD.ORG Sun Apr 22 14:04:46 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 88DDD106564A; Sun, 22 Apr 2012 14:04:46 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 18F0C8FC0C; Sun, 22 Apr 2012 14:04:46 +0000 (UTC) Received: by iahk25 with SMTP id k25so20079244iah.13 for ; Sun, 22 Apr 2012 07:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sDfQil1rKCiuwH/u3zqpGLfITZTizcL0/nwE92zYBvo=; b=ChoY7EPgV/MVwMxCeZsuS4o/y20LWJiMYCZvb62lKdPgZHMJAqlu+wCImgvBfbn554 aXyYZbXm4VrJwWYWChL86mpyhC4aUNHmVAeK1j2pQqniRSoixtIY3VWmvyeAMTPaBak2 S2UTD86x9rF/lPKuBBKMKOCnW2AbroMaZWly3vJ1Vzp9JtdoQjjh3N5ouaB3/8D2j+P+ eR3L0hDhz8XRJrb/cK3qbXmpFc39c7RRYgawscr2SFaKTLGiCxLIvNMS9URtv7w2Xlni 9XwalYw+mZxq+VZ4YMgLV2ZALZyK5x8IrJ+J814frhN0VQWLbuZYi2vcd6FVpv8/MUEj gHUQ== MIME-Version: 1.0 Received: by 10.50.168.67 with SMTP id zu3mr3990000igb.28.1335103485545; Sun, 22 Apr 2012 07:04:45 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.50.129.39 with HTTP; Sun, 22 Apr 2012 07:04:45 -0700 (PDT) In-Reply-To: References: <20120419133018.GA91364@onelab2.iet.unipi.it> <4F907011.9080602@freebsd.org> <20120419204622.GA94904@onelab2.iet.unipi.it> <20120419212224.GA95459@onelab2.iet.unipi.it> <20120420144410.GA3629@onelab2.iet.unipi.it> <20120421155638.E982@besplex.bde.org> Date: Sun, 22 Apr 2012 16:04:45 +0200 X-Google-Sender-Auth: 1uW3UVFv3AMADeG0duidTGqTUwY Message-ID: From: "K. Macy" To: Adrian Chadd Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Luigi Rizzo , Andre Oppermann , current@freebsd.org, net@freebsd.org Subject: Re: Some performance measurements on the FreeBSD network stack 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, 22 Apr 2012 14:04:46 -0000 Most of these issues are well known. Addressing the bottlenecks is simply time consuming due to the fact that any bugs introduced during development potentially impact many users. -Kip On Sun, Apr 22, 2012 at 4:14 AM, Adrian Chadd wrote: > Hi, > > This honestly sounds like it's begging for an > instrumentation/analysis/optimisation project. > > What do we need to do? > > > Adrian --=20 =A0 =A0=93The real damage is done by those millions who want to 'get by.' The ordinary men who just want to be left in peace. Those who don=92t want their little lives disturbed by anything bigger than themselves. Those with no sides and no causes. Those who won=92t take measure of their own strength, for fear of antagonizing their own weakness. Those who don=92t like to make waves=97or enemies. =A0 =A0Those for whom freedom, honour, truth, and principles are only literature. Those who live small, love small, die small. It=92s the reductionist approach to life: if you keep it small, you=92ll keep it under control. If you don=92t make any noise, the bogeyman won=92t find you. =A0 =A0But it=92s all an illusion, because they die too, those people who roll up their spirits into tiny little balls so as to be safe. Safe?! >From what? Life is always on the edge of death; narrow streets lead to the same place as wide avenues, and a little candle burns itself out just like a flaming torch does. =A0 =A0I choose my own way to burn.=94 =A0 =A0Sophie Scholl From owner-freebsd-net@FreeBSD.ORG Sun Apr 22 16:46:39 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 98049106566B for ; Sun, 22 Apr 2012 16:46:39 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5191E8FC08 for ; Sun, 22 Apr 2012 16:46:39 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SLzvo-0006RD-58 for freebsd-net@freebsd.org; Sun, 22 Apr 2012 18:46:36 +0200 Received: from www01.lwilke.de ([78.47.159.91]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Apr 2012 18:46:36 +0200 Received: from lw by www01.lwilke.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Apr 2012 18:46:36 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Lars Wilke Date: Sun, 22 Apr 2012 16:46:01 +0000 Lines: 17 Message-ID: <97pd69-nfr.ln1@lwilke.de> References: <8ol369-4nf.ln1@lwilke.de> <20120419114418.GE15520@cklennard.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: www01.lwilke.de User-Agent: slrn/0.9.9p1 (Linux) Subject: Re: Watchdog timeout em driver 8.2-R 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, 22 Apr 2012 16:46:39 -0000 * Lars Wilke wrote: > * Jack Vogel wrote: > > ok then i guess i will upgrade to 8.3-R, is the driver there reasonably > > new? > > > > Yes, that should be fine. Ok, with 8.3R everything seems to be stable, at least i could not reproduce the NIC resetting itself in last 4 houers now :) But i noticed that, i.e. dev.em.3.tx_dma_fail: 41316 is increasing rather quickly and my NFS write performance dropped rather badly. What does the tx_dma_fail mean? --lars From owner-freebsd-net@FreeBSD.ORG Mon Apr 23 01:26:56 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 B140A106566B; Mon, 23 Apr 2012 01:26:56 +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 846A68FC12; Mon, 23 Apr 2012 01:26:56 +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 q3N1QuP3073240; Mon, 23 Apr 2012 01:26:56 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3N1Qu1l073236; Mon, 23 Apr 2012 01:26:56 GMT (envelope-from yongari) Date: Mon, 23 Apr 2012 01:26:56 GMT Message-Id: <201204230126.q3N1Qu1l073236@freefall.freebsd.org> To: xxjack12xx@gmail.com, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/166724: [re] if_re watchdog timeout 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, 23 Apr 2012 01:26:56 -0000 Synopsis: [re] if_re watchdog timeout State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Mon Apr 23 01:25:58 UTC 2012 State-Changed-Why: Would you show me the output of "ifconfig re0"? Just sending large files from your box through re0 is enough to reproduce the issue? Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Apr 23 01:25:58 UTC 2012 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=166724 From owner-freebsd-net@FreeBSD.ORG Mon Apr 23 01:31:03 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 9E37D1065672; Mon, 23 Apr 2012 01:31:03 +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 717E38FC18; Mon, 23 Apr 2012 01:31:03 +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 q3N1V39s077768; Mon, 23 Apr 2012 01:31:03 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3N1V3eu077760; Mon, 23 Apr 2012 01:31:03 GMT (envelope-from yongari) Date: Mon, 23 Apr 2012 01:31:03 GMT Message-Id: <201204230131.q3N1V3eu077760@freefall.freebsd.org> To: xxjack12xx@gmail.com, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/166727: [msk] msk driver keeps erroring 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, 23 Apr 2012 01:31:03 -0000 Synopsis: [msk] msk driver keeps erroring State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Mon Apr 23 01:29:53 UTC 2012 State-Changed-Why: Would you try the diff at the following URL? http://svnweb.freebsd.org/base/stable/9/sys/dev/msk/if_msk.c?r1=229524&r2=229874&view=patch Also make sure to cold boot your box after applying the patch. Warm reboot may not address the issue. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Apr 23 01:29:53 UTC 2012 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=166727 From owner-freebsd-net@FreeBSD.ORG Mon Apr 23 01:35:59 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 6A86D106566C; Mon, 23 Apr 2012 01:35:59 +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 3E0DA8FC0A; Mon, 23 Apr 2012 01:35:59 +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 q3N1Zx7r083935; Mon, 23 Apr 2012 01:35:59 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3N1Zxg3083930; Mon, 23 Apr 2012 01:35:59 GMT (envelope-from yongari) Date: Mon, 23 Apr 2012 01:35:59 GMT Message-Id: <201204230135.q3N1Zxg3083930@freefall.freebsd.org> To: depocatcher@gmail.com, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/166894: [rl] Realtek RTL8100 keeps droping link 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, 23 Apr 2012 01:35:59 -0000 Synopsis: [rl] Realtek RTL8100 keeps droping link State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Mon Apr 23 01:34:58 UTC 2012 State-Changed-Why: Try set the following loader tunable in /boot/loader.conf and let me know whether that change makes any difference. dev.rl.0.twister_enable="1" Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Apr 23 01:34:58 UTC 2012 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=166894 From owner-freebsd-net@FreeBSD.ORG Mon Apr 23 01:40:35 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 69404106566B; Mon, 23 Apr 2012 01:40:35 +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 3C1098FC0C; Mon, 23 Apr 2012 01:40:35 +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 q3N1eZXu087126; Mon, 23 Apr 2012 01:40:35 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3N1eYKY087044; Mon, 23 Apr 2012 01:40:34 GMT (envelope-from yongari) Date: Mon, 23 Apr 2012 01:40:34 GMT Message-Id: <201204230140.q3N1eYKY087044@freefall.freebsd.org> To: universite@ukr.net, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/166909: [alc] NIC alc(4) does not support 1000baseTX 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, 23 Apr 2012 01:40:35 -0000 Synopsis: [alc] NIC alc(4) does not support 1000baseTX State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Mon Apr 23 01:39:37 UTC 2012 State-Changed-Why: Show me the output of "pciconf -lcbv" and dmesg output. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Apr 23 01:39:37 UTC 2012 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=166909 From owner-freebsd-net@FreeBSD.ORG Mon Apr 23 03:14:07 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 B80D0106566B; Mon, 23 Apr 2012 03:14:07 +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 8C12B8FC15; Mon, 23 Apr 2012 03:14:07 +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 q3N3E79K075301; Mon, 23 Apr 2012 03:14:07 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3N3E7FG075297; Mon, 23 Apr 2012 03:14:07 GMT (envelope-from linimon) Date: Mon, 23 Apr 2012 03:14:07 GMT Message-Id: <201204230314.q3N3E7FG075297@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/166940: [ipfilter] [panic] Double fault in kern 8.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: Mon, 23 Apr 2012 03:14:07 -0000 Old Synopsis: Double fault in kern 8.2 New Synopsis: [ipfilter] [panic] Double fault in kern 8.2 Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Apr 23 03:12:58 UTC 2012 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=166940 From owner-freebsd-net@FreeBSD.ORG Mon Apr 23 06:10:13 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 D94F9106566C for ; Mon, 23 Apr 2012 06:10:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AB5888FC12 for ; Mon, 23 Apr 2012 06:10:13 +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 q3N6ADv7032954 for ; Mon, 23 Apr 2012 06:10:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3N6ADX8032948; Mon, 23 Apr 2012 06:10:13 GMT (envelope-from gnats) Date: Mon, 23 Apr 2012 06:10:13 GMT Message-Id: <201204230610.q3N6ADX8032948@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Andrey Zonov Cc: Subject: Re: kern/166940: [ipfilter] [panic] Double fault in kern 8.2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrey Zonov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 06:10:13 -0000 The following reply was made to PR kern/166940; it has been noted by GNATS. From: Andrey Zonov To: bug-followup@FreeBSD.org, vampyr@mail.ru Cc: Subject: Re: kern/166940: [ipfilter] [panic] Double fault in kern 8.2 Date: Mon, 23 Apr 2012 10:05:40 +0400 Hi, Try my patch from this PR [1]. [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/155585 -- Andrey Zonov From owner-freebsd-net@FreeBSD.ORG Mon Apr 23 11:07:21 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 B82D81065675 for ; Mon, 23 Apr 2012 11:07:21 +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 9E8288FC1C for ; Mon, 23 Apr 2012 11:07: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 q3NB7Lra047654 for ; Mon, 23 Apr 2012 11:07:21 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3NB7L4P047652 for freebsd-net@FreeBSD.org; Mon, 23 Apr 2012 11:07:21 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 Apr 2012 11:07:21 GMT Message-Id: <201204231107.q3NB7L4P047652@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, 23 Apr 2012 11:07:21 -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/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/166550 net [netinet] [patch] Some log lines about arp do not incl 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/164569 net [msk] [hang] msk network driver cause freeze in FreeBS 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/164400 net [ipsec] immediate crash after the start of ipsec proce 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/162509 net [re] [panic] Kernel panic may be related to if_re.c (r 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/160420 net [msk] phy write timeout on HP 5310m 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/157429 net [re] Realtek RTL8169 doesn't work with re(4) 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 o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u 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 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/138620 net [lagg] [patch] lagg port bpf-writes blocked 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 s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if 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 s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress 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 s 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 403 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Apr 23 13:28:14 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 B542B106566B for ; Mon, 23 Apr 2012 13:28:14 +0000 (UTC) (envelope-from nokiacashsplash2012promo@nokia.com) Received: from nm4.access.bullet.mail.mud.yahoo.com (nm4.access.bullet.mail.mud.yahoo.com [66.94.237.205]) by mx1.freebsd.org (Postfix) with SMTP id 723FA8FC17 for ; Mon, 23 Apr 2012 13:28:14 +0000 (UTC) Received: from [66.94.237.127] by nm4.access.bullet.mail.mud.yahoo.com with NNFMP; 23 Apr 2012 13:25:56 -0000 Received: from [98.137.12.183] by tm2.access.bullet.mail.mud.yahoo.com with NNFMP; 23 Apr 2012 13:25:56 -0000 Received: from [127.0.0.1] by smtp108.biz.mail.gq1.yahoo.com with NNFMP; 23 Apr 2012 13:25:56 -0000 X-Yahoo-Newman-Id: 616493.23848.bm@smtp108.biz.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: AJTbiBAVM1na9SWFhGcAo3y1_P6B1e3kU_WW70igiPyiGry 6zJv9qmgsd3mzH.ak671jXyQXdY4eT31hPyNV8i8mHOtyZyr8X0WUBA.nJEQ WuI.3fbEoOTGsX1yRGVPQGjiC97Gvpsx1ySDdc.oEAiIVxwYbmbw6IuhVXEE msXLXU3dKGVnx_bRgv98ywCEoPJcnkgkQZ2ua.CpA5J48jhP5sM85PjMLI2l 8QjsyLHdprg5GxdCbqNDqyBBuHvjtagxJHWqEpbZX4rcG8emJ.aVPzqRNJJd LSgOzoKRE5E0xohgNlBxsq174h2w4DibdIc46ppj3_mhjORpVdFjjnIiLCUY EkIOcdGxdq6DpLYJkHRNkz4LXusAOJ6f_yACl_9RaHpeOMP7stkNkutoikLt 5beF9ezV_e4ZFIAa4JS1c_TCaJ2MPs94MsdHZKnC1Bgxx9QQ1imRbXoCMV_w kpuLAcQ-- X-Yahoo-SMTP: d5WEE92swBAQ.HI4psr6XPODUor2CUiwnRE- Received: from PICASO-HP (nokiacashsplash2012promo@41.203.64.133 with login) by smtp108.biz.mail.gq1.yahoo.com with SMTP; 23 Apr 2012 06:25:54 -0700 PDT Message-ID: <07b5e009-41022-0ab96012967824@picaso-hp> From: "Richard .A. Simonson" To: freebsd-net@freebsd.org Date: Mon, 23 Apr 2012 14:25:53 +0100 Content-Transfer-Encoding: 8bit X-Priority: 3 X-Mailer: Power Sending Sockets v5.1 MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Important Information. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Richard .A. Simonson" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 13:28:14 -0000 [logo.gif] _________________________________________________________________ Dear freebsd-net@freebsd.org, You or someone entered your information on our web Ad for the 2012 Nokia Cash Splash Promo and we are using this medium to officially notify you that the result of the promo was recently released as shown below: S/N Winners List Amount Won Ticket Number Status 1 mohamed.tinshah@shell.com 700,000.00 GBP Confidential Unclaimed 2 freebsd-net@freebsd.org 400,000.00 GBP NOK81124TF Unclaimed 3 ellen.fedrick@bluewin.ch 200,000.00 GBP Confidential Unclaimed We are happy to inform you that you are our second prize winner and you won 400,000.00 GBP (Four Hundred thousand Great British Pounds) at this promo. Your ticket number is NOK81124TF. Please take note of your ticket number as it will be needed for verification. To receive your prize money as soon as possible, simply fax us the following information for verification: 1. Your Full names 2. Residential/Office address 3. Phone number 4. Fax number 5.Email address 6. Occupation 7. Ticket number Your prize money will be released to you as soon as you have faxed the above information to our office for verification. Our fax number is +44-700-593-1181. The required information should be sent via fax only. Bear it in mind that you won big in this promo because you are one of our valuable customers. However, if you wish to decline the receipt of your prize money, you are to notify us on time so that the opportunity will be given to another Nokia phone user. WARNING: Because of numerous fraudulent schemes going around the internet, confidentiality should be accorded at all times. You are expected to keep the news of your winning and your ticket number to yourself until you have received your prize money. This is to avoid false claims and abuse of the program. Nokia Corporation will never ask you to pay any fee before you receive your prize money. You can call +44-702-405-4836 if you wish to speak to someone from our office. Congratulations!!! Richard A Simonson Chief Financial Officer Nokia Corporation - UK Tel: +44-702-405-4836 Web: http://www.nokia.com Copyright © 2012 Nokia Corporation. All rights reserved From owner-freebsd-net@FreeBSD.ORG Mon Apr 23 13:55:15 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 720F9106564A for ; Mon, 23 Apr 2012 13:55:15 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 21D4D8FC15 for ; Mon, 23 Apr 2012 13:55:15 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SMJjQ-0003Hh-3R for freebsd-net@freebsd.org; Mon, 23 Apr 2012 15:55:08 +0200 Received: from w4336.dip.tu-dresden.de ([141.76.185.80]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Apr 2012 15:55:08 +0200 Received: from js by w4336.dip.tu-dresden.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Apr 2012 15:55:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Julian Stecklina Date: Mon, 23 Apr 2012 15:54:58 +0200 Lines: 37 Message-ID: <87k4161rkd.fsf@alien8.de> References: <20120419133018.GA91364@onelab2.iet.unipi.it> <4F907011.9080602@freebsd.org> <20120419204622.GA94904@onelab2.iet.unipi.it> <20120419212224.GA95459@onelab2.iet.unipi.it> <20120420144410.GA3629@onelab2.iet.unipi.it> <20120421155638.E982@besplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: w4336.dip.tu-dresden.de User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:vEefavturl0Q5W87Op6KqtYaAak= Subject: Re: Some performance measurements on the FreeBSD network stack 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, 23 Apr 2012 13:55:15 -0000 Thus spake Bruce Evans : > On Fri, 20 Apr 2012, K. Macy wrote: > >> On Fri, Apr 20, 2012 at 4:44 PM, Luigi Rizzo wrote: > >>> The small penalty when flowtable is disabled but compiled in is >>> probably because the net.flowtable.enable flag is checked >>> a bit deep in the code. >>> >>> The advantage with non-connect()ed sockets is huge. I don't >>> quite understand why disabling the flowtable still helps there. >> >> Do you mean having it compiled in but disabled still helps >> performance? Yes, that is extremely strange. > > This reminds me that when I worked on this, I saw very large throughput > differences (in the 20-50% range) as a result of minor changes in > unrelated code. I could get these changes intentionally by adding or > removing padding in unrelated unused text space, so the differences were > apparently related to text alignment. I thought I had some significant > micro-optimizations, but it turned out that they were acting mainly by > changing the layout in related used text space where it is harder to > control. For short code paths, code layout can significantly influence performance. We have been puzzled (in a project unrelated to FreeBSD) by a 10% performance drop in some microbenchmark that was ultimately caused by having all our code hotspots linked at 8K aligned addresses, which caused them to evict each other from the L1 instruction cache, because its associativity was too small. A simple way to check for this would be to have the option to build a kernel with random linking order. I don't know how difficult it is to implement that in the current FreeBSD toolchain. Julian From owner-freebsd-net@FreeBSD.ORG Tue Apr 24 12:35:20 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 16F4D106564A for ; Tue, 24 Apr 2012 12:35:20 +0000 (UTC) (envelope-from hikolo.92@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id A03F68FC12 for ; Tue, 24 Apr 2012 12:35:19 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so3115999wib.13 for ; Tue, 24 Apr 2012 05:35:18 -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=x3cDwI8LflLKZvczMNfmdojisQQLrlgHArw7S64JA7I=; b=EXFOJKQOTcx0sxGWWlfGhfTxBuA0XbibbsTMsVMo9Nr1Z8/b+i1bBuoHoxuzJ4EQMC ehOWx6Wcp8hRwL/xos2w2ttwRlviDvdOfjKfJWYkyszAKG/+ZycUGJ+GTKzEuL38iKQb n2EzMOScoscDBcm926DcD9TPJG/AJkNh+ciQhy/9AnN0SOK59EFhoPgbI1Lj8k3O+PaF Ry+9ISdBaShyk4lSPYgpsGpN3qw0hcRXDyenw6kA2U4njSYJ8eeqCxWo72Amsv54X8d6 CIGCvfY8JyEBvAtCX1S+VbtE6S4DhSpm4o0PYpv7xHs9dWwRUaqKe6EDTCDpAW4RaxWH hQnA== MIME-Version: 1.0 Received: by 10.180.92.71 with SMTP id ck7mr31076334wib.2.1335270918581; Tue, 24 Apr 2012 05:35:18 -0700 (PDT) Received: by 10.223.118.17 with HTTP; Tue, 24 Apr 2012 05:35:18 -0700 (PDT) Date: Tue, 24 Apr 2012 14:35:18 +0200 Message-ID: From: Karl Stenlund To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Realtek 8111F 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, 24 Apr 2012 12:35:20 -0000 I installed freebsd 9.0_amd64 and it can't find my network. i tried to add "if_re_load="YES"" But it didn't help. Is the Realtek 8111F not suported by freebsd yet? Motherboard: ASUS P8H77-I From owner-freebsd-net@FreeBSD.ORG Tue Apr 24 13:17:03 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 8B7F5106566B for ; Tue, 24 Apr 2012 13:17:03 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id EF85E8FC1B for ; Tue, 24 Apr 2012 13:17:02 +0000 (UTC) Received: (qmail 43894 invoked from network); 24 Apr 2012 13:11:16 -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 ; 24 Apr 2012 13:11:16 -0000 Message-ID: <4F96A7C0.3010909@freebsd.org> Date: Tue, 24 Apr 2012 15:16:48 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Luigi Rizzo References: <20120419133018.GA91364@onelab2.iet.unipi.it> <4F907011.9080602@freebsd.org> <20120419204622.GA94904@onelab2.iet.unipi.it> In-Reply-To: <20120419204622.GA94904@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, net@freebsd.org Subject: Re: Some performance measurements on the FreeBSD network stack 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, 24 Apr 2012 13:17:03 -0000 On 19.04.2012 22:46, Luigi Rizzo wrote: > On Thu, Apr 19, 2012 at 10:05:37PM +0200, Andre Oppermann wrote: >> On 19.04.2012 15:30, Luigi Rizzo wrote: >>> I have been running some performance tests on UDP sockets, >>> using the netsend program in tools/tools/netrate/netsend >>> and instrumenting the source code and the kernel do return in >>> various points of the path. Here are some results which >>> I hope you find interesting. >>> - another big bottleneck is the route lookup in ip_output() >>> (between entries 51 and 56). Not only it eats another >>> 100ns+ on an empty routing table, but it also >>> causes huge contentions when multiple cores >>> are involved. >> >> This is indeed a big problem. I'm working (rough edges remain) on >> changing the routing table locking to an rmlock (read-mostly) which > > i was wondering, is there a way (and/or any advantage) to use the > fastforward code to look up the route for locally sourced packets ? I've completed the updating of the routing table rmlock patch. There are two steps. Step one is just changing the rwlock to an rmlock. Step two streamlines the route lookup in ip_output and ip_fastfwd by copying out the relevant data while only holding the rmlock instead of obtaining a reference to the route. Would be very interesting to see how your benchmark/profiling changes with these patches applied. http://svn.freebsd.org/changeset/base/234649 Log: Change the radix head lock to an rmlock (read mostly lock). There is some header pollution going on because rmlock's are not entirely abstracted and need per-CPU structures. A comment in _rmlock.h says this can be hidden if there were per-cpu linker magic/support. I don't know if we have that already. http://svn.freebsd.org/changeset/base/234650 Log: Add a function rtlookup() that copies out the relevant information from an rtentry instead of returning the rtentry. This avoids the need to lock the rtentry and to increase the refcount on it. Convert ip_output() to use rtlookup() in a simplistic way. Certain seldom used functionality may not work anymore and the flowtable isn't available at the moment. Convert ip_fastfwd() to use rtlookup(). This code is meant to be used for profiling and to be experimented with further to determine which locking strategy returns the best results. Make sure to apply this one as well: http://svn.freebsd.org/changeset/base/234648 Log: Add INVARIANT and WITNESS support to rm_lock locks and optimize the synchronization path by replacing a LIST of active readers with a TAILQ. Obtained from: Isilon Submitted by: mlaier -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Apr 24 13:42:57 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 B2B06106566B; Tue, 24 Apr 2012 13:42:57 +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 3A9F08FC0C; Tue, 24 Apr 2012 13:42:57 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id CCC4D7300B; Tue, 24 Apr 2012 16:02:28 +0200 (CEST) Date: Tue, 24 Apr 2012 16:02:28 +0200 From: Luigi Rizzo To: Andre Oppermann Message-ID: <20120424140228.GA58809@onelab2.iet.unipi.it> References: <20120419133018.GA91364@onelab2.iet.unipi.it> <4F907011.9080602@freebsd.org> <20120419204622.GA94904@onelab2.iet.unipi.it> <4F96A7C0.3010909@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F96A7C0.3010909@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org, net@freebsd.org Subject: Re: Some performance measurements on the FreeBSD network stack 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, 24 Apr 2012 13:42:57 -0000 On Tue, Apr 24, 2012 at 03:16:48PM +0200, Andre Oppermann wrote: > On 19.04.2012 22:46, Luigi Rizzo wrote: > >On Thu, Apr 19, 2012 at 10:05:37PM +0200, Andre Oppermann wrote: > >>On 19.04.2012 15:30, Luigi Rizzo wrote: > >>>I have been running some performance tests on UDP sockets, > >>>using the netsend program in tools/tools/netrate/netsend > >>>and instrumenting the source code and the kernel do return in > >>>various points of the path. Here are some results which > >>>I hope you find interesting. > >>>- another big bottleneck is the route lookup in ip_output() > >>> (between entries 51 and 56). Not only it eats another > >>> 100ns+ on an empty routing table, but it also > >>> causes huge contentions when multiple cores > >>> are involved. > >> > >>This is indeed a big problem. I'm working (rough edges remain) on > >>changing the routing table locking to an rmlock (read-mostly) which > > > >i was wondering, is there a way (and/or any advantage) to use the > >fastforward code to look up the route for locally sourced packets ? > > I've completed the updating of the routing table rmlock patch. There > are two steps. Step one is just changing the rwlock to an rmlock. > Step two streamlines the route lookup in ip_output and ip_fastfwd by > copying out the relevant data while only holding the rmlock instead > of obtaining a reference to the route. > > Would be very interesting to see how your benchmark/profiling changes > with these patches applied. If you want to give it a try yourself, the high level benchmark is just the 'netsend' program from tools/tools/netrate/netsend -- i am running something like for i in $X ; do netsend 10.0.0.2 5555 18 0 5 & done and the cardinality of $X can be used to test contention on the low layers (routing tables and interface/queues). >From previous tests, the difference between flowtable and routing table was small with a single process (about 5% or 50ns in the total packet processing time, if i remember well), but there was a large gain with multiple concurrent processes. Probably the change in throughput between HEAD and your branch is all you need. The info below shows that your gain is something around 100-200 ns depending on how good is the info that you return back (see below). My profiling changes were mostly aimed at charging the costs to the various layers. With my current setting (single process i7-870 @2933 MHz+Turboboost, ixgbe, FreeBSD HEAD, FLOWTABLE enabled, UDP) i see the following: File Function/description Total/delta nanoseconds user program sendto() 8 96 system call uipc_syscalls.c sys_sendto 104 uipc_syscalls.c sendit 111 uipc_syscalls.c kern_sendit 118 uipc_socket.c sosend uipc_socket.c sosend_dgram 146 137 sockbuf locking, mbuf alloc, copyin udp_usrreq.c udp_send 273 udp_usrreq.c udp_output 273 57 ip_output.c ip_output 330 198 route lookup, ip header setup if_ethersubr.c ether_output 528 162 MAC header lookup and construction, loopback checks if_ethersubr.c ether_output_frame 690 ixgbe.c ixgbe_mq_start 698 ixgbe.c ixgbe_mq_start_locked 720 ixgbe.c ixgbe_xmit 730 220 mbuf mangling, device programming -- packet on the wire 950 Removing flowtable increases the cost in ip_output() (obviously) but also in ether_output() (because the route does not have a lle entry so you need to call arpresolve on each packet). It also causes trouble in the device driver because the mbuf does not have a flowid set, so the ixgbe device driver puts the packet on the queue corresponding to the current CPU. If the process (as in my case) floats, one flow might end up on multiple queues. So in revising the route lookup i believe it would be good if we could also get at once most of the info that ether_output() is computing again and again. cheers luigi > http://svn.freebsd.org/changeset/base/234649 > Log: > Change the radix head lock to an rmlock (read mostly lock). > > There is some header pollution going on because rmlock's are > not entirely abstracted and need per-CPU structures. > > A comment in _rmlock.h says this can be hidden if there were > per-cpu linker magic/support. I don't know if we have that > already. > > http://svn.freebsd.org/changeset/base/234650 > Log: > Add a function rtlookup() that copies out the relevant information > from an rtentry instead of returning the rtentry. This avoids the > need to lock the rtentry and to increase the refcount on it. > > Convert ip_output() to use rtlookup() in a simplistic way. Certain > seldom used functionality may not work anymore and the flowtable > isn't available at the moment. > > Convert ip_fastfwd() to use rtlookup(). > > This code is meant to be used for profiling and to be experimented > with further to determine which locking strategy returns the best > results. > > Make sure to apply this one as well: > http://svn.freebsd.org/changeset/base/234648 > Log: > Add INVARIANT and WITNESS support to rm_lock locks and optimize the > synchronization path by replacing a LIST of active readers with a > TAILQ. > > Obtained from: Isilon > Submitted by: mlaier > > -- > Andre > _______________________________________________ > 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 Tue Apr 24 14:16:19 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 AF4C8106564A; Tue, 24 Apr 2012 14:16:19 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from plsvl-mailgw-02.bluecoat.com (plsvl-mailgw-02.bluecoat.com [199.91.133.12]) by mx1.freebsd.org (Postfix) with ESMTP id 8D39E8FC0A; Tue, 24 Apr 2012 14:16:19 +0000 (UTC) Received: from PWSVL-EXCHTS-01.internal.cacheflow.com (unknown [10.2.2.122]) by plsvl-mailgw-02.bluecoat.com (Postfix) with ESMTP id C2EE5200C8; Tue, 24 Apr 2012 07:17:36 -0700 (PDT) Received: from pwsvl-excmbx-05.internal.cacheflow.com ([fe80::f848:d461:9aa9:59a8]) by PWSVL-EXCHTS-01.internal.cacheflow.com ([fe80::5c50:e2ba:8115:4223%20]) with mapi id 14.01.0289.001; Tue, 24 Apr 2012 07:16:19 -0700 From: "Li, Qing" To: Luigi Rizzo Thread-Topic: Some performance measurements on the FreeBSD network stack Thread-Index: AQHNIhyqmxIlJMdUe0+llxsSqqHVrpaqduMA//+MHgQ= Date: Tue, 24 Apr 2012 14:16:18 +0000 Message-ID: References: <20120419133018.GA91364@onelab2.iet.unipi.it> <4F907011.9080602@freebsd.org> <20120419204622.GA94904@onelab2.iet.unipi.it> <4F96A7C0.3010909@freebsd.org>, <20120424140228.GA58809@onelab2.iet.unipi.it> In-Reply-To: <20120424140228.GA58809@onelab2.iet.unipi.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.91.133.85] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "current@freebsd.org" , "net@freebsd.org" Subject: RE: Some performance measurements on the FreeBSD network stack 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, 24 Apr 2012 14:16:19 -0000 >=0A= >From previous tests, the difference between flowtable and=0A= >routing table was small with a single process (about 5% or 50ns=0A= >in the total packet processing time, if i remember well),=0A= >but there was a large gain with multiple concurrent processes.=0A= >=0A= =0A= Yes, that sounds about right when we did the tests a long while ago.=0A= =0A= >=0A= > Removing flowtable increases the cost in ip_output()=0A= > (obviously) but also in ether_output() (because the=0A= > route does not have a lle entry so you need to call=0A= > arpresolve on each packet). =0A= >=0A= =0A= Yup.=0A= =0A= >=0A= > So in revising the route lookup i believe it would be good=0A= > if we could also get at once most of the info that=0A= > ether_output() is computing again and again.=0A= >=0A= =0A= Well, the routing table no longer maintains any lle info, so there=0A= isn't much to copy out the rtentry at the completion of route=0A= lookup.=0A= =0A= If I understood you correctly, you do believe there is a lot of value=0A= in Flowtable caching concept, but you are not suggesting we reverting=0A= back to having the routing table maintain L2 entries, are you ?=0A= =0A= --Qing=0A= From owner-freebsd-net@FreeBSD.ORG Tue Apr 24 15:03:58 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 358FF1065674; Tue, 24 Apr 2012 15:03:58 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id D60D48FC08; Tue, 24 Apr 2012 15:03:57 +0000 (UTC) Received: by iahk25 with SMTP id k25so1465899iah.13 for ; Tue, 24 Apr 2012 08:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=b3VoNSVPsJcux4E5Q+Iw+YOidjKRHdBH/NA92Ntiupk=; b=p0ObvLJARd8bLBj6wc1JAw0TBtARFRYGpWJetkjU0O+lthRG6VER3jR6L5tir8c4mc dZNPsS5v4KzepBrR8WLUSjT9d2V1vD+8auaKfDkTPkuIj6bsY5LuZQs7o1KIyOF3BYF+ Cr782UJUCT1F7r9TtlUfBxRy2g/tFKEELS1z70z0wrGX1ZEaYqY68Dyl0YHjnU0gwjWo QSkGdZWUfVv92kiY3whLRDPQriHyLU7SzaY8w6xxP0thnMan+Ltp+5pjzlx/czhT1hrA oYNI9usWgJCbxblA4Y8xjdpQ+ezNu36gQHdbXPxLrlAyWHOlGORfSg9F5CjUbSd+9jvL 1QQA== MIME-Version: 1.0 Received: by 10.50.168.67 with SMTP id zu3mr1968004igb.28.1335279837392; Tue, 24 Apr 2012 08:03:57 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.50.129.39 with HTTP; Tue, 24 Apr 2012 08:03:57 -0700 (PDT) In-Reply-To: References: <20120419133018.GA91364@onelab2.iet.unipi.it> <4F907011.9080602@freebsd.org> <20120419204622.GA94904@onelab2.iet.unipi.it> <4F96A7C0.3010909@freebsd.org> <20120424140228.GA58809@onelab2.iet.unipi.it> Date: Tue, 24 Apr 2012 17:03:57 +0200 X-Google-Sender-Auth: zs8TRRBPpxUefkZ2_TmpJ7LPH8E Message-ID: From: "K. Macy" To: "Li, Qing" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Luigi Rizzo , "current@freebsd.org" , "net@freebsd.org" Subject: Re: Some performance measurements on the FreeBSD network stack 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, 24 Apr 2012 15:03:58 -0000 On Tue, Apr 24, 2012 at 4:16 PM, Li, Qing wrote: >> > >From previous tests, the difference between flowtable and >>routing table was small with a single process (about 5% or 50ns >>in the total packet processing time, if i remember well), >>but there was a large gain with multiple concurrent processes. >> > > Yes, that sounds about right when we did the tests a long while ago. > >> >> Removing flowtable increases the cost in ip_output() >> (obviously) but also in ether_output() (because the >> route does not have a lle entry so you need to call >> arpresolve on each packet). >> > > Yup. > >> >> So in revising the route lookup i believe it would be good >> if we could also get at once most of the info that >> ether_output() is computing again and again. >> > > Well, the routing table no longer maintains any lle info, so there > isn't much to copy out the rtentry at the completion of route > lookup. > > If I understood you correctly, you do believe there is a lot of value > in Flowtable caching concept, but you are not suggesting we reverting > back to having the routing table maintain L2 entries, are you ? > One could try a similar conversion of the L2 table to an rmlock without copy while lock is held. -Kip --=20 =A0 =A0=93The real damage is done by those millions who want to 'get by.' The ordinary men who just want to be left in peace. Those who don=92t want their little lives disturbed by anything bigger than themselves. Those with no sides and no causes. Those who won=92t take measure of their own strength, for fear of antagonizing their own weakness. Those who don=92t like to make waves=97or enemies. =A0 =A0Those for whom freedom, honour, truth, and principles are only literature. Those who live small, love small, die small. It=92s the reductionist approach to life: if you keep it small, you=92ll keep it under control. If you don=92t make any noise, the bogeyman won=92t find you. =A0 =A0But it=92s all an illusion, because they die too, those people who roll up their spirits into tiny little balls so as to be safe. Safe?! >From what? Life is always on the edge of death; narrow streets lead to the same place as wide avenues, and a little candle burns itself out just like a flaming torch does. =A0 =A0I choose my own way to burn.=94 =A0 =A0Sophie Scholl From owner-freebsd-net@FreeBSD.ORG Tue Apr 24 15:05:31 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 DBD671065672; Tue, 24 Apr 2012 15:05:31 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7CFDF8FC0C; Tue, 24 Apr 2012 15:05:31 +0000 (UTC) Received: by ghrr20 with SMTP id r20so518562ghr.13 for ; Tue, 24 Apr 2012 08:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=XOki2Ujcm/Ff3bqRnDOH7b1BK0QB/Q4ls2I2bjLtX+E=; b=EbBWj9+6qAcCq6eFocS+kYmPOylK3W6dtHEX1bN3M8T6m03g+bzMXUfPOCUJP6RIES qIoOLdQrjI+OQ/c4HKBJzqQYjQGZ+57m+Oa1yqGriz9Z+8ylvnJ9KteVG2iq1elT6xHL bqYBq9Uj8lzoILsVFNGwnXWrwAhmctS26Sw7CVgXsemIYimRcEvS2NmPlHdE3wajuaZ6 iZ0Yo7+Mezj4CPqzJU2XnVrAHfNh4FqAoydfJC7FROpLZ5Va8eI9BhMw2RA9mYh6uj1U tXA4x3N6QVbYU/oD1x1G63V+1XNuYxRQPxuuzPO5mUbKsL+GjKK8i2b/ek7omeK7B0Eq ru6A== MIME-Version: 1.0 Received: by 10.50.156.229 with SMTP id wh5mr10655767igb.28.1335279925083; Tue, 24 Apr 2012 08:05:25 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.50.129.39 with HTTP; Tue, 24 Apr 2012 08:05:24 -0700 (PDT) In-Reply-To: References: <20120419133018.GA91364@onelab2.iet.unipi.it> <4F907011.9080602@freebsd.org> <20120419204622.GA94904@onelab2.iet.unipi.it> <4F96A7C0.3010909@freebsd.org> <20120424140228.GA58809@onelab2.iet.unipi.it> Date: Tue, 24 Apr 2012 17:05:24 +0200 X-Google-Sender-Auth: vJl9uA75cPyj3V4GFsCJthWxp6k Message-ID: From: "K. Macy" To: "Li, Qing" Content-Type: text/plain; charset=ISO-8859-1 Cc: Luigi Rizzo , "current@freebsd.org" , "net@freebsd.org" Subject: Re: Some performance measurements on the FreeBSD network stack 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, 24 Apr 2012 15:05:31 -0000 On Tue, Apr 24, 2012 at 5:03 PM, K. Macy wrote: > On Tue, Apr 24, 2012 at 4:16 PM, Li, Qing wrote: >>> >> >From previous tests, the difference between flowtable and >>>routing table was small with a single process (about 5% or 50ns >>>in the total packet processing time, if i remember well), >>>but there was a large gain with multiple concurrent processes. >>> >> >> Yes, that sounds about right when we did the tests a long while ago. >> >>> >>> Removing flowtable increases the cost in ip_output() >>> (obviously) but also in ether_output() (because the >>> route does not have a lle entry so you need to call >>> arpresolve on each packet). >>> >> >> Yup. >> >>> >>> So in revising the route lookup i believe it would be good >>> if we could also get at once most of the info that >>> ether_output() is computing again and again. >>> >> >> Well, the routing table no longer maintains any lle info, so there >> isn't much to copy out the rtentry at the completion of route >> lookup. >> >> If I understood you correctly, you do believe there is a lot of value >> in Flowtable caching concept, but you are not suggesting we reverting >> back to having the routing table maintain L2 entries, are you ? >> > > > One could try a similar conversion of the L2 table to an rmlock > without copy while lock is held. Odd .. *with* copy while lock is held. -Kip From owner-freebsd-net@FreeBSD.ORG Tue Apr 24 16:14:46 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 2C515106566C; Tue, 24 Apr 2012 16:14:46 +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 D9A968FC0A; Tue, 24 Apr 2012 16:14:45 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id EA3187300A; Tue, 24 Apr 2012 18:34:23 +0200 (CEST) Date: Tue, 24 Apr 2012 18:34:23 +0200 From: Luigi Rizzo To: "Li, Qing" Message-ID: <20120424163423.GA59530@onelab2.iet.unipi.it> References: <20120419133018.GA91364@onelab2.iet.unipi.it> <4F907011.9080602@freebsd.org> <20120419204622.GA94904@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "current@freebsd.org" , "net@freebsd.org" Subject: Re: Some performance measurements on the FreeBSD network stack 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, 24 Apr 2012 16:14:46 -0000 On Tue, Apr 24, 2012 at 02:16:18PM +0000, Li, Qing wrote: > > > >From previous tests, the difference between flowtable and > >routing table was small with a single process (about 5% or 50ns > >in the total packet processing time, if i remember well), > >but there was a large gain with multiple concurrent processes. > > > > Yes, that sounds about right when we did the tests a long while ago. > > > > > Removing flowtable increases the cost in ip_output() > > (obviously) but also in ether_output() (because the > > route does not have a lle entry so you need to call > > arpresolve on each packet). > > > > Yup. > > > > > So in revising the route lookup i believe it would be good > > if we could also get at once most of the info that > > ether_output() is computing again and again. > > > > Well, the routing table no longer maintains any lle info, so there > isn't much to copy out the rtentry at the completion of route > lookup. > > If I understood you correctly, you do believe there is a lot of value > in Flowtable caching concept, but you are not suggesting we reverting > back to having the routing table maintain L2 entries, are you ? I see a lot of value in caching in general. Especially for a bound socket it seems pointless to lookup the route, iface and mac address(es) on every single packet instead of caching them. And, routes and MAC addresses are volatile anyways so making sure that we do the lookup 1us closer to the actual use gives no additional guarantee. The frequency with which these info (routes and MAC addresses) change clearly influences the mechanism to validate the cache. I suppose we have the following options: - direct notification: a failure in a direct chain of calls can be used to invalidate the info cached in the socket. Similarly, some incoming traffic (e.g. TCP RST, FIN, ICMP messages) that reach a socket can invalidate the cached values - assume a minimum lifetime for the info (i think this is what happens in the flowtable) and flush it unconditionally every such interval (say 10ms). - if some info changes infrequently (e.g. MAC addresses) one could put a version number in the cached value and use it to validate the cache. cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Apr 24 16:18:30 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 C28C71065677; Tue, 24 Apr 2012 16:18:30 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 74B118FC19; Tue, 24 Apr 2012 16:18:30 +0000 (UTC) Received: by iahk25 with SMTP id k25so1570753iah.13 for ; Tue, 24 Apr 2012 09:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nRZxGhtqAKb5ZuOonbUPX+zKHWSU0cZYOaXj9eySR/E=; b=o2h7Wwwi82dMGOJCyLsUzKAZupEJ0Ny9nxw/w7Xn6H9lsPTwnaSrVK7bpt9bThwSZu 4uCH+HUYl4otufrZC+yfMK1xQewC6r6d6JpcwI0YxFuSUdcQW/MBqsUE/QiQqMsqnXEy oNLVDZjRdxqVMWrZaj/fv3H/RHnYeF1T5Wzvyq7Pc4Pd13EYTI5CLtqK/XBnhDeEX9mU zWD+6HOMPeQdZMXDmXMxZlKRlROciZB9HRilgqhneqW9lS9yO714S9Tm3KPLNcj1MMrV eIoyvLEcvHeSGos8HzjCEgVQQDJKZ+GgkIsXBYS8ruW5D3RZEFLGQH43nS6Itj/MnhDY 6oKg== MIME-Version: 1.0 Received: by 10.50.194.232 with SMTP id hz8mr10939191igc.38.1335284309757; Tue, 24 Apr 2012 09:18:29 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.50.129.39 with HTTP; Tue, 24 Apr 2012 09:18:29 -0700 (PDT) In-Reply-To: <20120424163423.GA59530@onelab2.iet.unipi.it> References: <20120419133018.GA91364@onelab2.iet.unipi.it> <4F907011.9080602@freebsd.org> <20120419204622.GA94904@onelab2.iet.unipi.it> <20120424163423.GA59530@onelab2.iet.unipi.it> Date: Tue, 24 Apr 2012 18:18:29 +0200 X-Google-Sender-Auth: Y42oDrej-EVrsrWTvXr2bEEFpgQ Message-ID: From: "K. Macy" To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Li, Qing" , "current@freebsd.org" , "net@freebsd.org" Subject: Re: Some performance measurements on the FreeBSD network stack 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, 24 Apr 2012 16:18:30 -0000 On Tue, Apr 24, 2012 at 6:34 PM, Luigi Rizzo wrote: > On Tue, Apr 24, 2012 at 02:16:18PM +0000, Li, Qing wrote: >> > >> >From previous tests, the difference between flowtable and >> >routing table was small with a single process (about 5% or 50ns >> >in the total packet processing time, if i remember well), >> >but there was a large gain with multiple concurrent processes. >> > >> >> Yes, that sounds about right when we did the tests a long while ago. >> >> > >> > Removing flowtable increases the cost in ip_output() >> > (obviously) but also in ether_output() (because the >> > route does not have a lle entry so you need to call >> > arpresolve on each packet). >> > >> >> Yup. >> >> > >> > So in revising the route lookup i believe it would be good >> > if we could also get at once most of the info that >> > ether_output() is computing again and again. >> > >> >> Well, the routing table no longer maintains any lle info, so there >> isn't much to copy out the rtentry at the completion of route >> lookup. >> >> If I understood you correctly, you do believe there is a lot of value >> in Flowtable caching concept, but you are not suggesting we reverting >> back to having the routing table maintain L2 entries, are you ? > > I see a lot of value in caching in general. > > Especially for a bound socket it seems pointless to lookup the > route, iface and mac address(es) on every single packet instead of > caching them. And, routes and MAC addresses are volatile anyways > so making sure that we do the lookup 1us closer to the actual use > gives no additional guarantee. > > The frequency with which these info (routes and MAC addresses) > change clearly influences the mechanism to validate the cache. > I suppose we have the following options: > > - direct notification: a failure in a direct chain of calls > =A0can be used to invalidate the info cached in the socket. > =A0Similarly, some incoming traffic (e.g. TCP RST, FIN, > =A0ICMP messages) that reach a socket can invalidate the cached values > - assume a minimum lifetime for the info (i think this is what > =A0happens in the flowtable) and flush it unconditionally > =A0every such interval (say 10ms). > - if some info changes infrequently (e.g. MAC addresses) one could > =A0put a version number in the cached value and use it to validate > =A0the cache. I have a patch that has been sitting around for a long time due to review cycle latency that caches a pointer to the rtentry (and llentry) in the the inpcb. Before each use the rtentry is checked against a generation number in the routing tree that is incremented on every routing table update. From owner-freebsd-net@FreeBSD.ORG Tue Apr 24 16:35:05 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 E0407106566B; Tue, 24 Apr 2012 16:35:05 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id 7D1F28FC15; Tue, 24 Apr 2012 16:35:05 +0000 (UTC) Received: from [10.2.1.1] (unknown [10.2.1.1]) by work.netasq.com (Postfix) with ESMTPSA id 4392C27040AD; Tue, 24 Apr 2012 18:35:41 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_F190818E-0258-42A4-9701-074232C7B372"; protocol="application/pkcs7-signature"; micalg=sha1 From: Fabien Thomas In-Reply-To: Date: Tue, 24 Apr 2012 18:35:03 +0200 Message-Id: <5C2FC09E-1873-4A97-8980-07B336D3DC44@netasq.com> References: <20120419133018.GA91364@onelab2.iet.unipi.it> <4F907011.9080602@freebsd.org> <20120419204622.GA94904@onelab2.iet.unipi.it> <20120424163423.GA59530@onelab2.iet.unipi.it> To: "K. Macy" X-Mailer: Apple Mail (2.1257) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "Li, Qing" , Luigi Rizzo , "current@freebsd.org" , "net@freebsd.org" Subject: Re: Some performance measurements on the FreeBSD network stack 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, 24 Apr 2012 16:35:06 -0000 --Apple-Mail=_F190818E-0258-42A4-9701-074232C7B372 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 >> > > I have a patch that has been sitting around for a long time due to > review cycle latency that caches a pointer to the rtentry (and > llentry) in the the inpcb. Before each use the rtentry is checked > against a generation number in the routing tree that is incremented on > every routing table update. Hi Kip, Is there a public location for the patch ? What can be done to speedup the commit: testing ? Fabien --Apple-Mail=_F190818E-0258-42A4-9701-074232C7B372-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 24 17:40:14 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 B7F1B106566C; Tue, 24 Apr 2012 17:40:14 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from plsvl-mailgw-02.bluecoat.com (plsvl-mailgw-02.bluecoat.com [199.91.133.12]) by mx1.freebsd.org (Postfix) with ESMTP id 95C578FC08; Tue, 24 Apr 2012 17:40:14 +0000 (UTC) Received: from PWSVL-EXCHTS-02.internal.cacheflow.com (unknown [10.2.2.126]) by plsvl-mailgw-02.bluecoat.com (Postfix) with ESMTP id E2285200D3; Tue, 24 Apr 2012 10:41:33 -0700 (PDT) Received: from pwsvl-excmbx-05.internal.cacheflow.com ([fe80::f848:d461:9aa9:59a8]) by PWSVL-EXCHTS-02.internal.cacheflow.com ([fe80::4910:317f:407:6ecc%14]) with mapi id 14.01.0289.001; Tue, 24 Apr 2012 10:40:14 -0700 From: "Li, Qing" To: Luigi Rizzo Thread-Topic: Some performance measurements on the FreeBSD network stack Thread-Index: AQHNIhyqmxIlJMdUe0+llxsSqqHVrpaqduMA//+MHgSAAJ5UgP//mxvg Date: Tue, 24 Apr 2012 17:40:13 +0000 Message-ID: References: <20120419133018.GA91364@onelab2.iet.unipi.it> <4F907011.9080602@freebsd.org> <20120419204622.GA94904@onelab2.iet.unipi.it> <20120424163423.GA59530@onelab2.iet.unipi.it> In-Reply-To: <20120424163423.GA59530@onelab2.iet.unipi.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.2.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "current@freebsd.org" , "net@freebsd.org" Subject: RE: Some performance measurements on the FreeBSD network stack 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, 24 Apr 2012 17:40:14 -0000 Yup, all good points. In fact we have considered all of these while doing the work. In case you haven't seen it already, we did write about these=20 issues in our paper and how we tried to address those, flow-table was one of the solutions. http://dl.acm.org/citation.cfm?id=3D1592641 --Qing > > > > Well, the routing table no longer maintains any lle info, so there > > isn't much to copy out the rtentry at the completion of route > > lookup. > > > > If I understood you correctly, you do believe there is a lot of value > > in Flowtable caching concept, but you are not suggesting we reverting > > back to having the routing table maintain L2 entries, are you ? >=20 > I see a lot of value in caching in general. >=20 > Especially for a bound socket it seems pointless to lookup the > route, iface and mac address(es) on every single packet instead of > caching them. And, routes and MAC addresses are volatile anyways > so making sure that we do the lookup 1us closer to the actual use > gives no additional guarantee. >=20 > The frequency with which these info (routes and MAC addresses) > change clearly influences the mechanism to validate the cache. > I suppose we have the following options: >=20 > - direct notification: a failure in a direct chain of calls > can be used to invalidate the info cached in the socket. > Similarly, some incoming traffic (e.g. TCP RST, FIN, > ICMP messages) that reach a socket can invalidate the cached values > - assume a minimum lifetime for the info (i think this is what > happens in the flowtable) and flush it unconditionally > every such interval (say 10ms). > - if some info changes infrequently (e.g. MAC addresses) one could > put a version number in the cached value and use it to validate > the cache. >=20 > cheers > luigi From owner-freebsd-net@FreeBSD.ORG Tue Apr 24 17:42:48 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 D3E9F1065673; Tue, 24 Apr 2012 17:42:48 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from plsvl-mailgw-02.bluecoat.com (plsvl-mailgw-02.bluecoat.com [199.91.133.12]) by mx1.freebsd.org (Postfix) with ESMTP id AE1CA8FC08; Tue, 24 Apr 2012 17:42:48 +0000 (UTC) Received: from PWSVL-EXCHTS-02.internal.cacheflow.com (unknown [10.2.2.126]) by plsvl-mailgw-02.bluecoat.com (Postfix) with ESMTP id 3F5AA200C8; Tue, 24 Apr 2012 10:44:08 -0700 (PDT) Received: from pwsvl-excmbx-05.internal.cacheflow.com ([fe80::f848:d461:9aa9:59a8]) by PWSVL-EXCHTS-02.internal.cacheflow.com ([fe80::4910:317f:407:6ecc%14]) with mapi id 14.01.0289.001; Tue, 24 Apr 2012 10:42:48 -0700 From: "Li, Qing" To: Fabien Thomas , "K. Macy" Thread-Topic: Some performance measurements on the FreeBSD network stack Thread-Index: AQHNIhyqmxIlJMdUe0+llxsSqqHVrpaqduMA//+MHgSAAJ5UgP//+4+AgAAEoYD//51DEA== Date: Tue, 24 Apr 2012 17:42:47 +0000 Message-ID: References: <20120419133018.GA91364@onelab2.iet.unipi.it> <4F907011.9080602@freebsd.org> <20120419204622.GA94904@onelab2.iet.unipi.it> <20120424163423.GA59530@onelab2.iet.unipi.it> <5C2FC09E-1873-4A97-8980-07B336D3DC44@netasq.com> In-Reply-To: <5C2FC09E-1873-4A97-8980-07B336D3DC44@netasq.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.2.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Luigi Rizzo , "current@freebsd.org" , "net@freebsd.org" Subject: RE: Some performance measurements on the FreeBSD network stack 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, 24 Apr 2012 17:42:49 -0000 > > > > I have a patch that has been sitting around for a long time due to > > review cycle latency that caches a pointer to the rtentry (and > > llentry) in the the inpcb. Before each use the rtentry is checked > > against a generation number in the routing tree that is incremented > on > > every routing table update. >=20 > Hi Kip, >=20 > Is there a public location for the patch ? > What can be done to speedup the commit: testing ? >=20 > Fabien I performed extensive review of this patch from Kip, and it was ready to go. Really good work.=20 Not sure what is stopping its commit into the tree. --Qing From owner-freebsd-net@FreeBSD.ORG Tue Apr 24 21:07:56 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 B9057106564A for ; Tue, 24 Apr 2012 21:07:56 +0000 (UTC) (envelope-from satishkamara@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 3CFF48FC12 for ; Tue, 24 Apr 2012 21:07:56 +0000 (UTC) Received: by lbbgm6 with SMTP id gm6so1120408lbb.13 for ; Tue, 24 Apr 2012 14:07:55 -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=pov0BjNjKUVWKsq2ZQxdnhluUIOtWq/rOK22ZvwzsRc=; b=lF1cKc38VMy2WGDx+J7tqUdeediyJ7RbC5+ACAwf8MLmEUelLIHOeG8vhIc/of6aZ0 fGQJagq3ichN2CBVFFqtwK3EUJlatkptGIZB0MblNXjeJUpn3+n8VSV5ZHp9+4ASkiXe oFx1DCUoPSRFoqTQpSIaRm73YrPwkMzsYu/7iQSzjNt+gY6twa5wpS/BWX7Fbc2CQdP2 uUR8mTl3ne7XPQVj/Iwqn2hVOW0hWY4k/H57v8TNs/Je57TsyatMDF63aWheFy3uyq6Y iIKOJJeD2RpFGI72dcW9OeAsulUezhBV/akZifuXvhDUpsI0EP3QCRX2cWcyQCBiYlQz B/kg== MIME-Version: 1.0 Received: by 10.112.48.6 with SMTP id h6mr1116773lbn.94.1335301675025; Tue, 24 Apr 2012 14:07:55 -0700 (PDT) Received: by 10.112.128.197 with HTTP; Tue, 24 Apr 2012 14:07:54 -0700 (PDT) Date: Tue, 24 Apr 2012 17:07:54 -0400 Message-ID: From: satish amara To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: LLA (Link local address) in FreeBSD route command 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, 24 Apr 2012 21:07:56 -0000 Hi, I am trying to see what is valid and is supported in latest FreeBSD Does BSD let user add routes to LLA destinations? Does BSD let user specify LLA gateway without specifying the scope? I see following man page which talks about scope but looks like it not supported in the latest. http://www.manpagez.com/man/8/route/ Thanks, Satish K Amara From owner-freebsd-net@FreeBSD.ORG Wed Apr 25 00:02:11 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 44C171065670; Wed, 25 Apr 2012 00:02:11 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id E461D8FC15; Wed, 25 Apr 2012 00:02:10 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id F05D525D3857; Wed, 25 Apr 2012 00:02:09 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id F0219BE4935; Wed, 25 Apr 2012 00:02:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id gHtqqP60aFJQ; Wed, 25 Apr 2012 00:02:07 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 9F1C5BE4934; Wed, 25 Apr 2012 00:02: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: Date: Wed, 25 Apr 2012 00:02:06 +0000 Content-Transfer-Encoding: 7bit Message-Id: <7FC5708C-429D-4077-9A3C-6272AB1316D9@FreeBSD.org> References: <20120419133018.GA91364@onelab2.iet.unipi.it> <4F907011.9080602@freebsd.org> <20120419204622.GA94904@onelab2.iet.unipi.it> <20120424163423.GA59530@onelab2.iet.unipi.it> <5C2FC09E-1873-4A97-8980-07B336D3DC44@netasq.com> To: "Li, Qing" X-Mailer: Apple Mail (2.1084) Cc: net@freebsd.org, "K. Macy" , current@freebsd.org Subject: Re: Some performance measurements on the FreeBSD network stack 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, 25 Apr 2012 00:02:11 -0000 On 24. Apr 2012, at 17:42 , Li, Qing wrote: >>> >>> I have a patch that has been sitting around for a long time due to >>> review cycle latency that caches a pointer to the rtentry (and >>> llentry) in the the inpcb. Before each use the rtentry is checked >>> against a generation number in the routing tree that is incremented >> on >>> every routing table update. >> >> Hi Kip, >> >> Is there a public location for the patch ? >> What can be done to speedup the commit: testing ? >> >> Fabien > > I performed extensive review of this patch from Kip, and it was > ready to go. Really good work. > > Not sure what is stopping its commit into the tree. Because there were leaks, there were 100% panics for IPv6, ... at least on the version I had seen in autumn last year. There is certainly no one more interested then me on these in, esp. for v6 where the removal of route caching a long time ago made nd6_nud_hint() a NOP with dst and rt being passed down as NULL only, and where we are doing up to three route lookups in the output path if no cached rt is passed down along from the ULP. If there is an updated patch, I'd love to see it. /bz -- 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 Wed Apr 25 00:11:29 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 2D678106566B; Wed, 25 Apr 2012 00:11:29 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id E1A728FC12; Wed, 25 Apr 2012 00:11:28 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q3P0B7Pi050614; Tue, 24 Apr 2012 17:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1335312668; bh=hcG8WaJbILWzEh0kCIls3xfvZpCkba1lhkY8EucwgEM=; h=Subject:From:Reply-To:To:Cc:Content-Type:Date:Message-ID: Mime-Version:Content-Transfer-Encoding; b=qewm5zrVAOQykuho7wckq8lxMj4gUK/KUj966dOIccrK1nxbMQnS0mZphCIW0lv3e fQ18TcGhtFv6pHBJikfMbo1k0VEdwsBwaaUnx3hB9h3spFmRYbuRHqZjLum6tlgKjQ Lt8uKanYMJdYOInd6QBq5DqFT+oYQPWbWhLfUV4M= From: Sean Bruno To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset="UTF-8" Date: Tue, 24 Apr 2012 17:11:07 -0700 Message-ID: <1335312667.11564.13.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 312668000 Cc: Jack Vogel , John Baldwin Subject: igb(4) Pondering a bind to cpu patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 00:11:29 -0000 http://people.freebsd.org/~sbruno/if_igb.c.txt Scenario I've just seen: 8 core machine 2 igb(4) interfaces set num_queues=4 igb0:0 --> cpu0 igb0:1 --> cpu1 igb0:2 --> cpu2 igb0:3 --> cpu3 igb1:0 --> cpu0 igb1:1 --> cpu1 igb1:2 --> cpu2 igb1:3 --> cpu3 I suspect, that we need a static global to keep track of what cpu last was last bound to a queue. My patch does do this, but I don't know if its the right thing. Since I'm doing multiple interfaces, I need to make sure I don't schedule a queue to a non existent cpu, so take a modulo of the counter and the number of cpus in the box. Perhaps not the most elegant solution, but its a thing? Sean From owner-freebsd-net@FreeBSD.ORG Wed Apr 25 01:02:25 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 E585B1065675 for ; Wed, 25 Apr 2012 01:02:25 +0000 (UTC) (envelope-from juli@clockworksquid.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 35E438FC1A for ; Wed, 25 Apr 2012 01:02:25 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so1227245wgb.31 for ; Tue, 24 Apr 2012 18:02:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=Ka2gCNteb+T/hw41ZsjC7eECi0JHNkQjrP0d3hVkVq4=; b=Ft7YfQOqv1zCJ0D5C0HdLe2TdB14ZAyn2QjOqSCcL/6zMiYckQ8gVflJeiq9ePVsAA Awcb/vDDPxJF5/BQVCXQyF7NSYQ7XkAMYl1/zNerdf8FBj3LrCQYC3m1vlpkQRVl7GIA CRXU57fwk5f1/szZ98jhQ28sCWiLn4sSneYFriiXs++QXnJT5IaISwiwrUip+0gArsjA sXzlTv0l4d4yiBFFF8dOTpL9CNfk3AFxjIeVXDzXpXunEtXWV5cDXEBdpmSaBM+f9uKY xmF09VduOWj8Sp0zQ9fDmlqRLHyg4ZE1Zj/zg2lXLgQEIEKLr+hNY0GLSvf3pjPvllbt 7Gww== Received: by 10.216.135.223 with SMTP id u73mr317687wei.117.1335315744089; Tue, 24 Apr 2012 18:02:24 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.216.110.67 with HTTP; Tue, 24 Apr 2012 18:02:03 -0700 (PDT) In-Reply-To: <1335312667.11564.13.camel@powernoodle-l7.corp.yahoo.com> References: <1335312667.11564.13.camel@powernoodle-l7.corp.yahoo.com> From: Juli Mallett Date: Tue, 24 Apr 2012 18:02:03 -0700 X-Google-Sender-Auth: 6H6E7qrbB6iYJbZSN3OzziLnZSQ Message-ID: To: sbruno@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlL46sd0VKAvsK29HccjFHSir6BsqPxAvmnpDB8Ne8+HZ9I+fnciFBm9o7rqXXki9NH7Pv5 Cc: "freebsd-net@freebsd.org" , Jack Vogel , John Baldwin Subject: Re: igb(4) Pondering a bind to cpu patch 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, 25 Apr 2012 01:02:26 -0000 On Tue, Apr 24, 2012 at 17:11, Sean Bruno wrote: > http://people.freebsd.org/~sbruno/if_igb.c.txt > > 8 core machine > 2 igb(4) interfaces > set num_queues=3D4 > > igb0:0 --> cpu0 > [...] > igb1:0 --> cpu0 > [...] > > I suspect, that we need a static global to keep track of what cpu last > was last bound to a queue. =C2=A0My patch does do this, but I don't know = if > its the right thing. > > Since I'm doing multiple interfaces, I need to make sure I don't > schedule a queue to a non existent cpu, so take a modulo of the counter > and the number of cpus in the box. This seems like a plausible approach, and certainly much more DWIM than what I've done in the past, which is to use cpuset with -x to bind each IRQ to a core by hand. If there were a way for interfaces to export queue information including any relevant IRQs, it would be easy to make a frontend that would use cpuset in a usable way, but right now that's the solution I've found most tenable and uninvasive. The question here is what behavior to assume the user wants when they restrict the number of queues, which is why putting the policy bits into userland would be preferable to this sort of scheme, I suppose. From owner-freebsd-net@FreeBSD.ORG Wed Apr 25 03:31:36 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 D60C01065673; Wed, 25 Apr 2012 03:31:36 +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 A6DF18FC14; Wed, 25 Apr 2012 03:31:36 +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 q3P3VaU2042824; Wed, 25 Apr 2012 03:31:36 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3P3Vapk042787; Wed, 25 Apr 2012 03:31:36 GMT (envelope-from yongari) Date: Wed, 25 Apr 2012 03:31:36 GMT Message-Id: <201204250331.q3P3Vapk042787@freefall.freebsd.org> To: m77@libero.it, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/164569: [msk] [hang] msk network driver cause freeze in FreeBSD 9.0 i386 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, 25 Apr 2012 03:31:36 -0000 Synopsis: [msk] [hang] msk network driver cause freeze in FreeBSD 9.0 i386 State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Wed Apr 25 03:31:01 UTC 2012 State-Changed-Why: Would you show me the output of both dmesg(8) and 'pciconf -lcbv'? Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Wed Apr 25 03:31:01 UTC 2012 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=164569 From owner-freebsd-net@FreeBSD.ORG Wed Apr 25 04:20:57 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 B036F106566B for ; Wed, 25 Apr 2012 04:20:57 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 600C98FC0C for ; Wed, 25 Apr 2012 04:20:57 +0000 (UTC) Received: by iahk25 with SMTP id k25so2536725iah.13 for ; Tue, 24 Apr 2012 21:20:57 -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=A++5rRdqanE2LE3x1CUrTWd+TUw1ZG8X6/z1JK/a/+4=; b=N26wfVXLiAlCDYwi+dRMfaR9wxT/tbbnFdtoqYpmBH7Rp6FlrKYXKIyPYZzXB3wc4A wapXK5RDgxfGWAFH6nmym4jEwLTkz7CTWnqUx+E1m/uEn8NYKZxbmLG7cS5/dTzan9qB LFaBlo65WA1le6YJFzmDM+bGamIR0iYutqX+c= 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=A++5rRdqanE2LE3x1CUrTWd+TUw1ZG8X6/z1JK/a/+4=; b=OCFhZ6B2HOJFHKJ3ggDrACgqOa/EQatG5izZTHbqXz2x7G16iDeNvaYkGMQcacWF7V d+hLOJ7Ir+iKccm6sX5q2vQlLtQBhz9J2+hp/Nf8vxUFLFyyh8u8Xa6nf3o/ZxhzIDvS ReOq7b+fB8GpNx3Uml+fzyyPGGV1A+2jYOKrWE/gbzZ7TnKu/3o35xYOcuZpct/Ucq0A 8+cd2pJm73xzX6Nl53WUjguCMT3UHihLan7ZGTlI37ryzZgrR2sLH4pjakLTR3ufTPex LKYtis3/IgAxT+KbvqSlcZC5GP6kNswkRktDsmMrbaDQC+ANoU55Lg8NHvxJaf3JKSil Fbdw== Received: by 10.50.157.137 with SMTP id wm9mr12553756igb.64.1335327657059; Tue, 24 Apr 2012 21:20:57 -0700 (PDT) Received: from DataIX.net (adsl-108-73-114-100.dsl.klmzmi.sbcglobal.net. [108.73.114.100]) by mx.google.com with ESMTPS id k8sm39918619igz.4.2012.04.24.21.20.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Apr 2012 21:20:56 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q3P4KrAb035966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Apr 2012 00:20:53 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q3P4KrkZ035953; Wed, 25 Apr 2012 00:20:53 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Wed, 25 Apr 2012 00:20:52 -0400 From: Jason Hellenthal To: satish amara Message-ID: <20120425042052.GA29615@DataIX.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: X-Gm-Message-State: ALoCoQmJq28g1LLV7HITv92Cqssbg/v/zDR/kk0WGARhh7s0FQeHECSTFffmfA13eVu0M4oqevMe Cc: freebsd-net@freebsd.org Subject: Re: LLA (Link local address) in FreeBSD route command 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, 25 Apr 2012 04:20:57 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable First off lets start by referencing something that is correct and staying within-band instead of OOB. http://www.freebsd.org/cgi/man.cgi?query=3Droute Review that page and if you still have any questions then please ask again. On Tue, Apr 24, 2012 at 05:07:54PM -0400, satish amara wrote: > Hi, >=20 > I am trying to see what is valid and is supported in latest > FreeBSD >=20 > Does BSD let user add routes to LLA destinations? >=20 > Does BSD let user specify LLA gateway without specifying the scope? >=20 >=20 > I see following man page which talks about scope but looks like it not > supported in the latest. >=20 > http://www.manpagez.com/man/8/route/ >=20 >=20 > Thanks, >=20 > Satish K Amara > _______________________________________________ > 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" --=20 - (2^(N-1)) --FCuugMFkClbJLl1L Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJPl3ujAAoJEBSh2Dr1DU7W3fMH/17CSmp1z3ExfgzY9PrX5p2p 75GKEPW39faup3Kf7qfWyHwZIaGOCWDnhWdQvv0soEakCzkgun98spUn0SFFn0yk 2yHKVRc2FuS/FRY1c9SiBThaX/XyqYqaHp8h9YO/HaNB4UFywjueKOCrPEFx6bWo jmvO6PWuBp9EnjMyi/61jvS5NgmLmIHI02b4ixCvgMaDKq2Zig39SezRDSCbz3ra Rj+nE2gXe2KaPW6cXL/2mu+Vqx4Cb3VliYRklquYz98fc+Z5Fqb5YdmBD4NhlBUE K/kznAwntLJdW5nYoNjdgqSbJbY26jkrSt8Uv2LyA0AQRWpnvOFHL48re1moFZg= =vwsv -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 25 04:30:41 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 F1417106564A; Wed, 25 Apr 2012 04:30:41 +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 C4A228FC14; Wed, 25 Apr 2012 04:30:41 +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 q3P4UfV0094308; Wed, 25 Apr 2012 04:30:41 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3P4UfuK094301; Wed, 25 Apr 2012 04:30:41 GMT (envelope-from yongari) Date: Wed, 25 Apr 2012 04:30:41 GMT Message-Id: <201204250430.q3P4UfuK094301@freefall.freebsd.org> To: srg.gavrilov@gmail.com, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/157429: [re] Realtek RTL8169 doesn't work with re(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: Wed, 25 Apr 2012 04:30:42 -0000 Synopsis: [re] Realtek RTL8169 doesn't work with re(4) State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Wed Apr 25 04:29:45 UTC 2012 State-Changed-Why: Try diff at the following URL and let me know how it goes. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Wed Apr 25 04:29:45 UTC 2012 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=157429 From owner-freebsd-net@FreeBSD.ORG Wed Apr 25 04:34:36 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 C8FA4106566C; Wed, 25 Apr 2012 04:34:36 +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 9B9D88FC12; Wed, 25 Apr 2012 04:34:36 +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 q3P4Ya8k002602; Wed, 25 Apr 2012 04:34:36 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3P4YZa8002598; Wed, 25 Apr 2012 04:34:35 GMT (envelope-from yongari) Date: Wed, 25 Apr 2012 04:34:35 GMT Message-Id: <201204250434.q3P4YZa8002598@freefall.freebsd.org> To: david.keller@litchis.fr, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/162509: [re] [panic] Kernel panic may be related to if_re.c (realtek 8168 ) 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, 25 Apr 2012 04:34:36 -0000 Synopsis: [re] [panic] Kernel panic may be related to if_re.c (realtek 8168 ) State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Wed Apr 25 04:33:24 UTC 2012 State-Changed-Why: There had been a lot of change since 8.1-RELEASE. Could you reproduce this on 8.3-RELEASE? If yes, please show me full back trace information on 8.3-RELEASE. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Wed Apr 25 04:33:24 UTC 2012 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=162509 From owner-freebsd-net@FreeBSD.ORG Wed Apr 25 05:09:04 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 3E52A106564A for ; Wed, 25 Apr 2012 05:09:04 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0DC248FC0A for ; Wed, 25 Apr 2012 05:09:04 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so1052674pbc.13 for ; Tue, 24 Apr 2012 22:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=BuN52qSbkTkwPjKMk7qrY9CbQtwGxk8Vo+3L6xfmIYs=; b=qUbfW1FJAj7XtR/ErvSa5igC4My5fKX0SQki2aepNuVK8UWultBgmc8KIy+crbJJdb NepPtPI38P7zTZ56HJmag64Gz1OOEOap/sv5Jw/kBApkBw/sAjBQ0eD8+NwByE+4j03o r8HNWkB4gmrsKBAGYMoB986p/MgOrRm8c6hwD+MP7xsBtHQkQTAp5eBEuSTuXvi1LGFA +1HdeUJQq9rpHTyde/TSKcaDeKYmWW4bR6y2YIWBJFaDoVpesPPPOWXLnhrIuzYht8ro g0m3DW+WVsZQCCUgoEuAO88UyakSJ6W7yjujDYGftNM+1sZGKebo2SRwsx5fT+i59bd5 G9iA== Received: by 10.68.218.7 with SMTP id pc7mr4782957pbc.4.1335330543859; Tue, 24 Apr 2012 22:09:03 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id i1sm19431719pbv.49.2012.04.24.22.09.00 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Apr 2012 22:09:02 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 25 Apr 2012 14:08:56 -0700 From: YongHyeon PYUN Date: Wed, 25 Apr 2012 14:08:56 -0700 To: Karl Stenlund Message-ID: <20120425210856.GB8498@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Realtek 8111F X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 05:09:04 -0000 On Tue, Apr 24, 2012 at 02:35:18PM +0200, Karl Stenlund wrote: > I installed freebsd 9.0_amd64 and it can't find my network. i tried to add > "if_re_load="YES"" But it didn't help. > Is the Realtek 8111F not suported by freebsd yet? > Motherboard: ASUS P8H77-I Support for RTL8168/8111F was added after releasing 9.0-RELEASE. Use 8.3-RELEASE or latest stable. Alternatively download the following files from HEAD and rebuild kernel on 9.0-RELEASE. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rl.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rlreg.h From owner-freebsd-net@FreeBSD.ORG Wed Apr 25 07:59:55 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 9D6E5106564A for ; Wed, 25 Apr 2012 07:59:55 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from plsvl-mailgw-02.bluecoat.com (plsvl-mailgw-02.bluecoat.com [199.91.133.12]) by mx1.freebsd.org (Postfix) with ESMTP id 762D38FC12 for ; Wed, 25 Apr 2012 07:59:55 +0000 (UTC) Received: from PWSVL-EXCHTS-01.internal.cacheflow.com (unknown [10.2.2.122]) by plsvl-mailgw-02.bluecoat.com (Postfix) with ESMTP id 58C97200FE; Wed, 25 Apr 2012 01:01:23 -0700 (PDT) Received: from pwsvl-excmbx-05.internal.cacheflow.com ([fe80::f848:d461:9aa9:59a8]) by PWSVL-EXCHTS-01.internal.cacheflow.com ([fe80::5c50:e2ba:8115:4223%20]) with mapi id 14.01.0289.001; Wed, 25 Apr 2012 00:59:54 -0700 From: "Li, Qing" To: Ryan Stone Thread-Topic: Removing an IPv6 address does not remove NDP entries on that subnet Thread-Index: AQHNFquDKnm8fp7HXk2nAeZML12AZpaTPOVsgACG8wCAAQVyFoAWegdA Date: Wed, 25 Apr 2012 07:59:53 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.91.133.85] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: freebsd-net Subject: RE: Removing an IPv6 address does not remove NDP entries on that subnet 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, 25 Apr 2012 07:59:55 -0000 The patch is located at http://people.freebsd.org/~qingli/nd6_prefix.diff Please give it a try. I did only basic testing as of now and will do more tomorrow. --Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Li, Qing > Sent: Tuesday, April 10, 2012 5:43 PM > To: Ryan Stone > Cc: freebsd-net > Subject: RE: Removing an IPv6 address does not remove NDP entries on > that subnet >=20 > > > > [rstone@vm-head ~]ndp -a > > Neighbor Linklayer Address Netif Expire > S Flags > > 1::2 08:00:27:1e:b8:16 em0 7s > R > > fe80::a00:27ff:fefa:8732%em0 08:00:27:fa:87:32 em0 > permanent R > > rstone@vm-head ~]uname -a > > FreeBSD vm-head 10.0-CURRENT FreeBSD 10.0-CURRENT #10 r233549:233552M: > > Wed Mar 28 10:27:20 EDT 2012 > > >=20 > I don't know when this basic functionality was broken. I cannot verify > when the breakage > occurred on the 8.x systems I have because I am traveling at the moment. >=20 > I can take ownership of this bug and get it fixed as soon as I return > in 1.5 weeks. >=20 > --Qing > _______________________________________________ > 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 Wed Apr 25 09:22:14 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 567F51065675; Wed, 25 Apr 2012 09:22:14 +0000 (UTC) (envelope-from maxim@freebsd.org) Received: from mp2.macomnet.net (ipv6.irc.int.ru [IPv6:2a02:28:1:2::1b:2]) by mx1.freebsd.org (Postfix) with ESMTP id CAB5C8FC0A; Wed, 25 Apr 2012 09:22:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.14.5/8.14.5) with ESMTP id q3P9M67T053104; Wed, 25 Apr 2012 13:22:06 +0400 (MSK) (envelope-from maxim@freebsd.org) Date: Wed, 25 Apr 2012 13:22:06 +0400 (MSK) From: Maxim Konovalov To: "Li, Qing" In-Reply-To: Message-ID: References: <20120419133018.GA91364@onelab2.iet.unipi.it> <4F907011.9080602@freebsd.org> <20120419204622.GA94904@onelab2.iet.unipi.it> <20120424163423.GA59530@onelab2.iet.unipi.it> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Luigi Rizzo , "current@freebsd.org" , "net@freebsd.org" Subject: RE: Some performance measurements on the FreeBSD network stack 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, 25 Apr 2012 09:22:14 -0000 Hi, On Tue, 24 Apr 2012, 17:40-0000, Li, Qing wrote: > Yup, all good points. In fact we have considered all of these while doing > the work. In case you haven't seen it already, we did write about these > issues in our paper and how we tried to address those, flow-table was one > of the solutions. > > http://dl.acm.org/citation.cfm?id=1592641 Is this article available for those without ACM subscription? -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Wed Apr 25 10:19:33 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 920FD106564A; Wed, 25 Apr 2012 10:19:33 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3F9388FC18; Wed, 25 Apr 2012 10:19:33 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1SMzKF-00024f-VT; Wed, 25 Apr 2012 14:19:55 +0400 Date: Wed, 25 Apr 2012 14:19:55 +0400 From: Slawa Olhovchenkov To: Maxim Konovalov Message-ID: <20120425101955.GF76983@zxy.spb.ru> References: <20120419133018.GA91364@onelab2.iet.unipi.it> <4F907011.9080602@freebsd.org> <20120419204622.GA94904@onelab2.iet.unipi.it> <20120424163423.GA59530@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: "Li, Qing" , Luigi Rizzo , "current@freebsd.org" , "net@freebsd.org" Subject: Re: Some performance measurements on the FreeBSD network stack 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, 25 Apr 2012 10:19:33 -0000 On Wed, Apr 25, 2012 at 01:22:06PM +0400, Maxim Konovalov wrote: > Hi, > > On Tue, 24 Apr 2012, 17:40-0000, Li, Qing wrote: > > > Yup, all good points. In fact we have considered all of these while doing > > the work. In case you haven't seen it already, we did write about these > > issues in our paper and how we tried to address those, flow-table was one > > of the solutions. > > > > http://dl.acm.org/citation.cfm?id=1592641 > > Is this article available for those without ACM subscription? Tip: get citation from abstract to google. 3'th link: http://conferences.sigcomm.org/sigcomm/2009/workshops/presto/papers/p37.pdf From owner-freebsd-net@FreeBSD.ORG Wed Apr 25 10:41:52 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 C4F35106566B for ; Wed, 25 Apr 2012 10:41:52 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.zvne.fer.hr (slavko2.zvne.fer.hr [161.53.66.5]) by mx1.freebsd.org (Postfix) with ESMTP id 4E4198FC08 for ; Wed, 25 Apr 2012 10:41:51 +0000 (UTC) Received: from munja.zvne.fer.hr (161.53.66.248) by mail.zvne.fer.hr (161.53.66.5) with Microsoft SMTP Server id 14.1.355.2; Wed, 25 Apr 2012 12:41:49 +0200 Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Apr 2012 12:41:49 +0200 Received: from localhost ([161.53.19.8]) by sluga.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Apr 2012 12:41:48 +0200 From: Marko Zec To: Date: Wed, 25 Apr 2012 12:41:04 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <201204251241.04752.zec@fer.hr> X-OriginalArrivalTime: 25 Apr 2012 10:41:49.0028 (UTC) FILETIME=[04A81A40:01CD22D0] Subject: Intel 10 GbE cards (ixgbe) 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, 25 Apr 2012 10:41:52 -0000 Hi all, Although the ixgbe driver appears to have code for both 82598 and 82599 chipsets, the manual page stil lists only 82598 based cards as officially supported. Does anybody have first-hand experiences with 82599 based cards and recent versions of the ixgbe driver (-CURRENT, 9.0, 8.3)? Thanks, Marko From owner-freebsd-net@FreeBSD.ORG Wed Apr 25 11:22:03 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 0CCD2106566C for ; Wed, 25 Apr 2012 11:22:03 +0000 (UTC) (envelope-from ndenev@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 908898FC15 for ; Wed, 25 Apr 2012 11:22:02 +0000 (UTC) Received: by weyt57 with SMTP id t57so1372099wey.13 for ; Wed, 25 Apr 2012 04:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=D1JFtkP9Re3HUSWjBKbrrr/UhcZNzf5aospgo72j6RM=; b=s4Ikvu9o1xoUS4coiWvp9VTYxW7mfT7cKWtjYYP6Eqt0fxDoXh/AJlZrOVJnBPMa4/ noFdGiw9ZV/svfEwYYnQWPbiD0h0d+CpV6nDwTxsDYpv1PITc1TdaRSIEmKRN9qmAvF5 aR+pTkDdUaQB6DfhbVYzOxwfvvH6E59BtkBPbCSpYX9NwVZTCQnWZy7smsDGVCoeC2YD IK2DJimlPhAaRqaK9MNmDa1X53xCE9tPt4QTwPI/0B5aiEm2EkGMuDgnhPN4opVvqO7u 2oIPi78mBMPtEPHD0cV1Is083kzj68zOkoee7/9VemtQzZepjwguj8C4ZNMgKYdh3e/d sl2w== Received: by 10.216.137.27 with SMTP id x27mr1445605wei.70.1335352921540; Wed, 25 Apr 2012 04:22:01 -0700 (PDT) Received: from ndenevsa.sf.moneybookers.net (g1.moneybookers.com. [217.18.249.148]) by mx.google.com with ESMTPS id o2sm57654947wiv.11.2012.04.25.04.21.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Apr 2012 04:21:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: <201204251241.04752.zec@fer.hr> Date: Wed, 25 Apr 2012 14:21:58 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <385944CA-F490-4BEE-A200-92489E414926@gmail.com> References: <201204251241.04752.zec@fer.hr> To: Marko Zec X-Mailer: Apple Mail (2.1257) Cc: freebsd-net@freebsd.org Subject: Re: Intel 10 GbE cards (ixgbe) 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, 25 Apr 2012 11:22:03 -0000 On Apr 25, 2012, at 1:41 PM, Marko Zec wrote: > Hi all, >=20 > Although the ixgbe driver appears to have code for both 82598 and = 82599=20 > chipsets, the manual page stil lists only 82598 based cards as = officially=20 > supported. Does anybody have first-hand experiences with 82599 based = cards=20 > and recent versions of the ixgbe driver (-CURRENT, 9.0, 8.3)? >=20 > Thanks, >=20 > Marko > _______________________________________________ > 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" We are using about 10-15 of them without issues on 8.3 and 9.0 STABLE : ix0@pci0:6:0:0: class=3D0x020000 card=3D0x7a118086 chip=3D0x10fb8086 = rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82599EB 10-Gigabit SFI/SFP+ Network Connection' class =3D network subclass =3D ethernet ix1@pci0:6:0:1: class=3D0x020000 card=3D0x7a118086 chip=3D0x10fb8086 = rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82599EB 10-Gigabit SFI/SFP+ Network Connection' class =3D network subclass =3D ethernet Earlier versions had some issues with vlan tagged traffic, but now they = seem pretty stable here. Regards, Nikolay= From owner-freebsd-net@FreeBSD.ORG Wed Apr 25 11:25:58 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 1F3451065670 for ; Wed, 25 Apr 2012 11:25:58 +0000 (UTC) (envelope-from syuu@dokukino.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 D8E048FC0A for ; Wed, 25 Apr 2012 11:25:57 +0000 (UTC) Received: by obhx4 with SMTP id x4so338077obh.13 for ; Wed, 25 Apr 2012 04:25:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=yj2oPRLsJF/ORlpGlC/2UjpFgWnLFWTw/YX3+7F9Bxo=; b=ng3SWzZhPxd+qJV+AFvE3iF38NvDjmegEBf4gjhWpb321zIEDK6i/bjbJrKZzqyxpe l7K4c903yrYaqtwPr58hrqjaTFqhSfzyfKb2G+p9MfTYjWjZ3T3A550Qh27ji52hv6L8 vwhnG57sq/lYYNg7j6zUQ4s3lOpKHegLxpcECJaw6O9VSfgZAUIBKxmlYH9EDKMIRZeQ FRFP1ejmhzbQL99eM04gpr9Smya6WAA9FzsTyHZwmc57zLnpWGpxbIQFlCCNPH3OheHh RlkbbHt+VrBpeHrFkz3wwWvWJpji/icWfdhp4pYDDsPew6xIAjYxKsbBfOVeWtK0s1lu MewQ== Received: by 10.60.4.1 with SMTP id g1mr2679472oeg.55.1335353157481; Wed, 25 Apr 2012 04:25:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.204.71 with HTTP; Wed, 25 Apr 2012 04:25:16 -0700 (PDT) In-Reply-To: <201204251241.04752.zec@fer.hr> References: <201204251241.04752.zec@fer.hr> From: Takuya ASADA Date: Wed, 25 Apr 2012 20:25:16 +0900 Message-ID: To: Marko Zec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnD2K9GOtQfcDM7EqDiFoa+zjWgDmH2yVu6/2x76coTkutMORLGyJbC5TL1jbNfodUKg3LY Cc: freebsd-net@freebsd.org Subject: Re: Intel 10 GbE cards (ixgbe) 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, 25 Apr 2012 11:25:58 -0000 Hi Marko, I had working on bpf multiqueue support with 82599 in last year(on -CURRENT), there's no issue for me. http://freebsd.1045724.n5.nabble.com/Multiqueue-support-for-bpf-td4703899.h= tml Takuya ASADA 2012/4/25 Marko Zec : > Hi all, > > Although the ixgbe driver appears to have code for both 82598 and 82599 > chipsets, the manual page stil lists only 82598 based cards as officially > supported. =C2=A0Does anybody have first-hand experiences with 82599 base= d cards > and recent versions of the ixgbe driver (-CURRENT, 9.0, 8.3)? > > Thanks, > > Marko > _______________________________________________ > 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 Wed Apr 25 13:35:30 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 ABBA6106564A; Wed, 25 Apr 2012 13:35:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 81F128FC15; Wed, 25 Apr 2012 13:35:30 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E204CB915; Wed, 25 Apr 2012 09:35:29 -0400 (EDT) From: John Baldwin To: sbruno@freebsd.org Date: Wed, 25 Apr 2012 09:32:21 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <1335312667.11564.13.camel@powernoodle-l7.corp.yahoo.com> In-Reply-To: <1335312667.11564.13.camel@powernoodle-l7.corp.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201204250932.21378.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 25 Apr 2012 09:35:30 -0400 (EDT) Cc: "freebsd-net@freebsd.org" , Jack Vogel Subject: Re: igb(4) Pondering a bind to cpu patch 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, 25 Apr 2012 13:35:30 -0000 On Tuesday, April 24, 2012 8:11:07 pm Sean Bruno wrote: > http://people.freebsd.org/~sbruno/if_igb.c.txt > > Scenario I've just seen: > > 8 core machine > 2 igb(4) interfaces > set num_queues=4 > > igb0:0 --> cpu0 > igb0:1 --> cpu1 > igb0:2 --> cpu2 > igb0:3 --> cpu3 > > igb1:0 --> cpu0 > igb1:1 --> cpu1 > igb1:2 --> cpu2 > igb1:3 --> cpu3 > > I suspect, that we need a static global to keep track of what cpu last > was last bound to a queue. My patch does do this, but I don't know if > its the right thing. > > Since I'm doing multiple interfaces, I need to make sure I don't > schedule a queue to a non existent cpu, so take a modulo of the counter > and the number of cpus in the box. > > Perhaps not the most elegant solution, but its a thing? CPU IDs are not guaranteed to be dense. However, you can use CPU_FIRST() and CPU_NEXT() with your static global instead. OTOH, if igb were to just leave the interrupts alone instead of binding them by hand, they would get round-robin assigned among available cores already. I think in this case the best approach might be to add a tunable to disable igb's manual binding and instead let the default system round-robin be preserved. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Apr 25 14:13:12 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 B71BB1065672 for ; Wed, 25 Apr 2012 14:13:12 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6E0C98FC15 for ; Wed, 25 Apr 2012 14:13:12 +0000 (UTC) Received: by ghrr20 with SMTP id r20so156017ghr.13 for ; Wed, 25 Apr 2012 07:13:12 -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=vNR8H+7WW3cnYucgPCL3gfhqEoYtsDsDXiBSeeV0mvI=; b=d/nlD03dt8bvYmiR6pYwcnIOoB8119/MHmO2n8itICU2QWZQqSzTQw9yM1pFSwnRL/ 6dUEovP+bEbgzdv45ufbWpjanVk/+UgBzVGB8xO1+lbHjQa5Oygf+4vWSLHJA7uEjpej MK8057pdGwaszQ7kYu1eKudhktdz3ZAHKT32gnVaRONVqUnyjX3sPbq9AJi2CGiJ4scq N2NP6M/nc1eXlB0ugaXXJNuA5Qcu7vbGFK6qI+R1VRFC2V8fpaEkuYNkhEOOYI+PZGru abxUA+hjnMWua//y1RDFfVaSAjnA+DdWJ2XDNIAkRCK/AdiVqCP9BXz6as9wz1hiZPdf pvPw== MIME-Version: 1.0 Received: by 10.60.7.196 with SMTP id l4mr947072oea.8.1335363191853; Wed, 25 Apr 2012 07:13:11 -0700 (PDT) Received: by 10.182.166.100 with HTTP; Wed, 25 Apr 2012 07:13:11 -0700 (PDT) In-Reply-To: References: <201204251241.04752.zec@fer.hr> Date: Wed, 25 Apr 2012 17:13:11 +0300 Message-ID: From: Sami Halabi To: Takuya ASADA Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Marko Zec Subject: Re: Intel 10 GbE cards (ixgbe) 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, 25 Apr 2012 14:13:12 -0000 Hi, I have it running on fbsd-8.1-r for more than 1.5 years now without issues, i had problem when i first installed it, but they were disappeared when i installed 2.3.8 driver, today there is 2.4 versionon stable. Sami On Wed, Apr 25, 2012 at 2:25 PM, Takuya ASADA wrote: > Hi Marko, > > I had working on bpf multiqueue support with 82599 in last year(on > -CURRENT), there's no issue for me. > > http://freebsd.1045724.n5.nabble.com/Multiqueue-support-for-bpf-td4703899.html > > Takuya ASADA > > 2012/4/25 Marko Zec : > > Hi all, > > > > Although the ixgbe driver appears to have code for both 82598 and 82599 > > chipsets, the manual page stil lists only 82598 based cards as officially > > supported. Does anybody have first-hand experiences with 82599 based > cards > > and recent versions of the ixgbe driver (-CURRENT, 9.0, 8.3)? > > > > Thanks, > > > > Marko > > _______________________________________________ > > 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" > -- Sami Halabi Information Systems Engineer NMS Projects Expert From owner-freebsd-net@FreeBSD.ORG Wed Apr 25 15:45:12 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 ADEB11065678; Wed, 25 Apr 2012 15:45:12 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 334A18FC15; Wed, 25 Apr 2012 15:45:12 +0000 (UTC) Received: by yhgm50 with SMTP id m50so282009yhg.13 for ; Wed, 25 Apr 2012 08:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=vlR8m2g4tqqSz11sCsSsUkgtpcLTaR1ytOav32j6jpU=; b=U/Xu3awCKqpc0VWcVq0gyrDAOF0COtnqtc29mwN83N5w/p3t33/hOOKFOM6wf+muxu 2a5/Wr2PNcRvnz30fGGXfnPIFB+fXw8AJB7OHqk/YdI/FccQYPOsYEjCdkaz5+0716lq UR1h8Q9rS8zorSJwtwlHStk1GL3AU/zI+JSh1IABIRKDN+uGCKXQkUpnmneZBhXEleXX UM7eMMDdWxnVk+uKdCKKEeCkUbM9YQaEI5zHeGypJ7N6G7N5cOsqC1/FlHjN+wYroo9k /8Cn4SLtrv4dRNtcVq6JPFEZr+x5DfO7UrwiXoFk6CIAFmvy2K20mb+3GuRJDO5AIcMO Iymg== MIME-Version: 1.0 Received: by 10.50.51.197 with SMTP id m5mr3196478igo.38.1335368711190; Wed, 25 Apr 2012 08:45:11 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.50.129.39 with HTTP; Wed, 25 Apr 2012 08:45:11 -0700 (PDT) In-Reply-To: <7FC5708C-429D-4077-9A3C-6272AB1316D9@FreeBSD.org> References: <20120419133018.GA91364@onelab2.iet.unipi.it> <4F907011.9080602@freebsd.org> <20120419204622.GA94904@onelab2.iet.unipi.it> <20120424163423.GA59530@onelab2.iet.unipi.it> <5C2FC09E-1873-4A97-8980-07B336D3DC44@netasq.com> <7FC5708C-429D-4077-9A3C-6272AB1316D9@FreeBSD.org> Date: Wed, 25 Apr 2012 17:45:11 +0200 X-Google-Sender-Auth: fwlNrlBMvWtLhOyHzd2aIp2Yc7w Message-ID: From: "K. Macy" To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Cc: "Li, Qing" , Fabien Thomas , current@freebsd.org, net@freebsd.org Subject: Re: Some performance measurements on the FreeBSD network stack 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, 25 Apr 2012 15:45:12 -0000 > Because there were leaks, there were 100% panics for IPv6, ... at least on > the version I had seen in autumn last year. > > There is certainly no one more interested then me on these in, esp. for v6 > where the removal of route caching a long time ago made nd6_nud_hint() a NOP > with dst and rt being passed down as NULL only, and where we are doing up to > three route lookups in the output path if no cached rt is passed down along > from the ULP. > > If there is an updated patch, I'd love to see it. Ok, I'm following up as this seems to be getting some interest. This the relevant part of the last mail that I received from you. The final part having been dedicated to the narrow potential ABI changes that were to make it in to the release. From: Bjoern A. Zeeb Date: Mon, Sep 19, 2011 at 3:19 PM To: "K. Macy" Cc: Robert Watson , rysto32 , Qing Li Sorry it's taking me so long while I was travelling but also now being back home again. I would yet have to find a code path through IPv6 that will a) not panic on INVARIANTS and b) actually update the inp_lle cache. Once I stop finding the next hiccup going one step deeper into the stack (and I made it to if_ethersubr.c) I'll get to legacy IP and the beef and I'll hope that all you all will have reviewed and tested that thoroughly. Checking whether a similar problem would exist in v4 I however found a possible lle reference leak in the legacy IP path as well. There's also a missed place where we do not update the generation counter (even though kind of pointless place but still to do for completeness). I am also pondering why we are not always invalidating the ro_lle cache (when we update the ro_rt entry in the callgraph after tcp_output). I wonder if we can provoke strange results say changing the default route from something connected on interface 1 to interface 2. <...> /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. =================================================================== The only comment in here which was sufficiently specific to actually take action on was: "pondering why we are not always invalidating the ro_lle cache (when we update the ro_rt entry in the callgraph after tcp_output)." Which was subsequently addressed by ensuring that the LLE_VALID flag was actually meaningful by clearing it when the llentry is removed from the interface's hash table in an unrelated commit because of weird behaviour observed with the flow. a) Where is the possible leak in the legacy path? b) Where were the panics in v6? In light of the fact that I don't or at least didn't have any means of testing v6 (I can probably get a testbed set up at iX now) and the netinet6 specific portions of the patch consist of 4 lines of code which should really be entrusted to you given that your performance parity work for v6 has actively being funded, it was clearly a mistake to tie the fate of the patch as a whole to those narrow bits. Once I get a response to a) and b) I'll follow up with a patch against head. I'm sure whatever I had has bitrotted somewhat in the meantime. Thanks for your help, Kip From owner-freebsd-net@FreeBSD.ORG Wed Apr 25 18:53:41 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 5C54F106564A; Wed, 25 Apr 2012 18:53:41 +0000 (UTC) (envelope-from bz@freebsd.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id D2DD38FC0C; Wed, 25 Apr 2012 18:53:40 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id D03BE25D3A00; Wed, 25 Apr 2012 18:53:39 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id EAF7DBE59D1; Wed, 25 Apr 2012 18:53:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id GiC1C+NlZvzd; Wed, 25 Apr 2012 18:53:37 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 25B06BE59CF; Wed, 25 Apr 2012 18:53:37 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: Date: Wed, 25 Apr 2012 18:53:36 +0000 Content-Transfer-Encoding: 7bit Message-Id: References: <20120419133018.GA91364@onelab2.iet.unipi.it> <4F907011.9080602@freebsd.org> <20120419204622.GA94904@onelab2.iet.unipi.it> <20120424163423.GA59530@onelab2.iet.unipi.it> <5C2FC09E-1873-4A97-8980-07B336D3DC44@netasq.com> <7FC5708C-429D-4077-9A3C-6272AB1316D9@FreeBSD.org> To: K. Macy X-Mailer: Apple Mail (2.1084) Cc: current@freebsd.org, net@freebsd.org Subject: Re: Some performance measurements on the FreeBSD network stack 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, 25 Apr 2012 18:53:41 -0000 On 25. Apr 2012, at 15:45 , K. Macy wrote: > a) Where is the possible leak in the legacy path? It's been somewhere in ip_output() in one of the possible combinations go through the code flow. I'd probably need to apply a patch to a tree to get there again. It's been more than 6 months for me as well. I think it was related to the flowtable path but I could completely misremember. > b) Where were the panics in v6? Again completely quoting from memory. I think the problem was that the INVARIANTS check in what's currently nd6_output_lle() was hit given both the rtentry and llentry were passed in but no *chain. Fixing this seems trivial even when trying to keep the current invariants checked. However the bigger problem then was that the cached value was never updated as the *ro passed down had been lost on the way. Whatever came then, is again off my head without the patch in front of me. Btw. you don't need more than two machines connected, virtual or not, worst two vnet instances on a lab machine, to enable and do IPv6. No need for global connectivity at all, as would not be required for IPv4 either. If you can get the patch updated to apply to a modern HEAD and compile (even if as-is) I'll try to help solving those to my best (though limited) availability to help you to get that thing in. /bz -- 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 Wed Apr 25 19:30:39 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 6BB15106566B; Wed, 25 Apr 2012 19:30:39 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 21E308FC0A; Wed, 25 Apr 2012 19:30:39 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q3PJUQu4098474; Wed, 25 Apr 2012 12:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1335382227; bh=fdx9vknuJmDbcIGLOIqu4xzwS4AN9eJw55m/IH4v7+8=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=L4r1QBUhRB5bipjKeB52TV1MGVSIj0V0F37HuUO3+fFC/b9SmPKo3xoiTN69Wucx0 mTvYui2HybIX7Z3k9RVkrhNWdFs+3feOqN2zafcFZPIla+pgI3hpzpXyP/+k1+fvqU Dgcqag1N4x6pI22hJON3jJtAR2bpn2iXH+3CpJds= From: Sean Bruno To: John Baldwin In-Reply-To: <201204250932.21378.jhb@freebsd.org> References: <1335312667.11564.13.camel@powernoodle-l7.corp.yahoo.com> <201204250932.21378.jhb@freebsd.org> Content-Type: text/plain; charset="UTF-8" Date: Wed, 25 Apr 2012 12:30:25 -0700 Message-ID: <1335382225.2722.6.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 382226000 Cc: "freebsd-net@freebsd.org" , Jack Vogel Subject: Re: igb(4) Pondering a bind to cpu patch 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, 25 Apr 2012 19:30:39 -0000 On Wed, 2012-04-25 at 06:32 -0700, John Baldwin wrote: > CPU IDs are not guaranteed to be dense. However, you can use > CPU_FIRST() and > CPU_NEXT() with your static global instead. > Ah, does CPU_NEXT() reset to 0 when it reaches the end of its list of CPUs? > OTOH, if igb were to just leave the interrupts alone instead of > binding them > by hand, they would get round-robin assigned among available cores > already. I > think in this case the best approach might be to add a tunable to > disable > igb's manual binding and instead let the default system round-robin > be > preserved. also, yes. Why *are* we binding to CPUs in the first place? Are we afraid that the scheduler won't do the right thing and we're trying to work around some unknown performance issue ? Sean From owner-freebsd-net@FreeBSD.ORG Wed Apr 25 19:44:10 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 89C97106566B; Wed, 25 Apr 2012 19:44:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5D78E8FC1B; Wed, 25 Apr 2012 19:44:10 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C9A86B915; Wed, 25 Apr 2012 15:44:09 -0400 (EDT) From: John Baldwin To: Sean Bruno Date: Wed, 25 Apr 2012 15:43:08 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <1335312667.11564.13.camel@powernoodle-l7.corp.yahoo.com> <201204250932.21378.jhb@freebsd.org> <1335382225.2722.6.camel@powernoodle-l7.corp.yahoo.com> In-Reply-To: <1335382225.2722.6.camel@powernoodle-l7.corp.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201204251543.09099.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 25 Apr 2012 15:44:09 -0400 (EDT) Cc: "freebsd-net@freebsd.org" , Jack Vogel Subject: Re: igb(4) Pondering a bind to cpu patch 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, 25 Apr 2012 19:44:10 -0000 On Wednesday, April 25, 2012 3:30:25 pm Sean Bruno wrote: > On Wed, 2012-04-25 at 06:32 -0700, John Baldwin wrote: > > CPU IDs are not guaranteed to be dense. However, you can use > > CPU_FIRST() and > > CPU_NEXT() with your static global instead. > > > Ah, does CPU_NEXT() reset to 0 when it reaches the end of its list of > CPUs? Yes. > > OTOH, if igb were to just leave the interrupts alone instead of > > binding them > > by hand, they would get round-robin assigned among available cores > > already. I > > think in this case the best approach might be to add a tunable to > > disable > > igb's manual binding and instead let the default system round-robin > > be > > preserved. > > also, yes. Why *are* we binding to CPUs in the first place? Are we > afraid that the scheduler won't do the right thing and we're trying to > work around some unknown performance issue ? Well, in some cases you want to know exactly which CPUs are being used as you might bind other resources associated with the queue to those specific CPUs as well. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Apr 25 22:03:47 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 A9D551065673 for ; Wed, 25 Apr 2012 22:03:47 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245]) by mx1.freebsd.org (Postfix) with ESMTP id 5899C8FC12 for ; Wed, 25 Apr 2012 22:03:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id 67BF9446002; Wed, 25 Apr 2012 18:03:24 -0400 (EDT) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2Ncf3CKVuNq; Wed, 25 Apr 2012 18:03:19 -0400 (EDT) Received: from riven.arriad.com (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id 47166446009; Wed, 25 Apr 2012 18:03:19 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) From: Andrew Boyer In-Reply-To: Date: Wed, 25 Apr 2012 18:03:34 -0400 Message-Id: <131F4CD6-5C3B-4C43-85E8-726D87527290@averesystems.com> References: <10A2858D-8DA8-45C4-B9A6-00CFA172404F@averesystems.com> To: Jack Vogel X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Ryan Stone , Jack Vogel Subject: Re: Bad interaction between 82599 hardware RSC and VLANs 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, 25 Apr 2012 22:03:47 -0000 Any update on this? -Andrew On Jan 13, 2012, at 6:04 PM, Jack Vogel wrote: > Hey Andrew, >=20 > Not heard of this before, but I'll check around. >=20 > Jack >=20 >=20 > On Fri, Jan 13, 2012 at 3:01 PM, Andrew Boyer = wrote: > Hello Jack, > I'm seeing an issue on 82599 controllers. When hardware RSC is used, = large VLAN packets arrive without the VP bit set, even though the vtag = in the descriptor is correct. It totally kills the receive performance. = Turning off hardware RSC in the driver (falling back to software LRO) = works fine, as does turning off LRO entirely. >=20 > I've worked around the problem for now by overriding the VP bit if = ixgbe_rxeof() finds a valid vtag in the descriptor. >=20 > Have you seen this before? >=20 > It's not in the latest errata. It almost seems to be the opposite of = what Ryan reported in November 2010 ("82599 receiving packets with vlan = tag=3D0 (vlan strip problem)?"). >=20 > Thanks, > Andrew >=20 > -------------------------------------------------- > Andrew Boyer aboyer@averesystems.com >=20 >=20 >=20 >=20 > _______________________________________________ > 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" >=20 -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-net@FreeBSD.ORG Thu Apr 26 00:46:25 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 E5281106566B for ; Thu, 26 Apr 2012 00:46:25 +0000 (UTC) (envelope-from ccowart@bitgravity.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 A3EF88FC14 for ; Thu, 26 Apr 2012 00:46:25 +0000 (UTC) Received: by obhx4 with SMTP id x4so992727obh.13 for ; Wed, 25 Apr 2012 17:46:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent:x-gm-message-state; bh=EoNiqN8u3zjcy7v+vs1xjIrm3E7A2kXmGGBWSK0EVHo=; b=Ili5QFRrYpDMw76rZMU6W7eLmB6d3V4eGqLhQv6rxlGB0HIi6zNZ8bQb5+oGkRKZ7X ipVJ7QLWtF30Gqk6Rf++QY9Uhjsig3CEhhIXUNygeWodZ/Hj5fVJN/znSUzqqbG8Rxc7 6S0wjJzTPW5wCTl76YIc3KnMnqQmjVqIVKwmKpDWeGTwdpYQzBglXFQyisBi/cqRXqkL gycerpQYdAaZ1hEAee1SEtP73PNA5zaTk23mgl4Pkc6KHvjA2Z3SDEHsmInIR2lPKQOs rKT6INlYt2MNC+xi8smDuuAeiz+F8PT8Ma8yHgj55ywRh/tYJV5ZYbcA0N6O+q0VoQFR DUIQ== Received: by 10.182.183.73 with SMTP id ek9mr6445435obc.15.1335401185292; Wed, 25 Apr 2012 17:46:25 -0700 (PDT) Received: from netops-194.sfo1.bitgravity.com (netops-209.sfo1.bitgravity.com. [209.131.110.209]) by mx.google.com with ESMTPS id j10sm1712732oba.4.2012.04.25.17.46.24 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Apr 2012 17:46:24 -0700 (PDT) Date: Wed, 25 Apr 2012 17:46:22 -0700 From: Chris Cowart To: freebsd-net@freebsd.org Message-ID: <20120426004621.GB1315@netops-194.sfo1.bitgravity.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+g7M9IMkV8truYOl" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Gm-Message-State: ALoCoQmZd10cEqk1AKBvsgXZsUQc44+5zBTk6iPb367femzsZxOmuRea9cnPK/IrMcvK3vM8uTO6 Subject: Kernel panic when using deprecated prefix on stf(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: Thu, 26 Apr 2012 00:46:26 -0000 --+g7M9IMkV8truYOl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello,=20 I'm currently trying to configure an stf(4) interface to make 2002::/16 directly reachable from hosts with native IPv6. The "output-only" example at the end of the EXAMPLES section of stf(4) leads to consistent kernel panics for me. I've observed the panics on 8.1. The example looks like this: # ifconfig ne0 inet 133.4.5.6 netmask 0xffffff00 # ifconfig stf0 inet6 2002:8504:0506:0000:a00:5aff:fe38:6f86 \ prefixlen 16 alias deprecated link0 # route add -inet6 2002:: -prefixlen 16 ::1 # route change -inet6 2002:: -prefixlen 16 ::1 -ifp stf0 I've narrowed the panics down to this: # ifconfig stf0 create # ifconfig stf0 inet6 2002:480d:5667::1/16 deprecated The "link0" flag appears to just disable decapsulation (making it impossible to ping6 2002:480d:5667::1). It has no effect on the crash. I've tried various iterations of the route add/change commands in my experimenting; I don't think they're necessary. The routing table looks like this immediately following bringing stf0 up with a deprecated prefix: | $ route get -inet6 2002::/16 | route to: 2002:: | destination: 2002:: | mask: ffff:: | interface: stf0 | flags: | recvpipe sendpipe ssthresh rtt,msec mtu weight expire | 0 0 0 0 1280 1 0=20 And 2002::/16 hosts ping. Generally within 2-3 minutes (often much sooner), I get a kernel panic. I've been able to reproduce the issue on our custom 8.1 build on Xen and bare metal as well as on a stock 8.1-RELEASE-p5 running in an ESX vm. I don't think you'll have any trouble seeing the same results. The backtraces have been all over the place. Here are a couple of samples: | Fatal trap 12: page fault while in kernel mode | cpuid =3D 1; apic id =3D 02 | fault virtual address =3D 0x420 | fault code =3D supervisor write data, page not present | instruction pointer =3D 0x20:0xffffffff805013bc | stack pointer =3D 0x28:0xffffff80000438b0 | frame pointer =3D 0x28:0xffffff80000438d0 | code segment =3D base 0x0, limit 0xfffff, type 0x1b | =3D DPL 0, pres 1, long 1, def32 0, gran 1 | processor eflags =3D interrupt enabled, resume, IOPL =3D 0 | current process =3D 12 (swi4: clock) | trap number =3D 12 | panic: page fault | cpuid =3D 1 | KDB: stack backtrace: | db_trace_self_wrapper() at db_trace_self_wrapper+0x2a | panic() at panic+0x182 | trap_fatal() at trap_fatal+0x2ad | trap_pfault() at trap_pfault+0x22d | trap() at trap+0x369 | calltrap() at calltrap+0x8 | --- trap 0xc, rip =3D 0xffffffff805013bc, rsp =3D 0xffffff80000438b0, rbp= =3D 0xffffff80000438d0 --- | _mtx_lock_flags() at _mtx_lock_flags+0x1c | in6_purgeaddr() at in6_purgeaddr+0x59 | nd6_timer() at nd6_timer+0x8f | softclock() at softclock+0x2a2 | intr_event_execute_handlers() at intr_event_execute_handlers+0x66 | ithread_loop() at ithread_loop+0x8e | fork_exit() at fork_exit+0x112 | fork_trampoline() at fork_trampoline+0xe | --- trap 0, rip =3D 0, rsp =3D 0xffffff8000043d30, rbp =3D 0 --- | Uptime: 57s | Fatal trap 12: page fault while in kernel mode | cpuid =3D 1; apic id =3D 02 | fault virtual address =3D 0x420 | fault code =3D supervisor write data, page not present | instruction pointer =3D 0x20:0xffffffff805013bc | stack pointer =3D 0x28:0xffffff80000438b0 | frame pointer =3D 0x28:0xffffff80000438d0 | code segment =3D base 0x0, limit 0xfffff, type 0x1b | =3D DPL 0, pres 1, long 1, def32 0, gran 1 | processor eflags =3D interrupt enabled, resume, IOPL =3D 0 | current process =3D 12 (swi4: clock) | trap number =3D 12 | panic: page fault | cpuid =3D 1 | KDB: stack backtrace: | db_trace_self_wrapper() at db_trace_self_wrapper+0x2a | panic() at panic+0x182 | trap_fatal() at trap_fatal+0x2ad | trap_pfault() at trap_pfault+0x22d | trap() at trap+0x369 | calltrap() at calltrap+0x8 | --- trap 0xc, rip =3D 0xffffffff805013bc, rsp =3D 0xffffff80000438b0, rbp= =3D 0xffffff80000438d0 --- | _mtx_lock_flags() at _mtx_lock_flags+0x1c | in6_purgeaddr() at in6_purgeaddr+0x59 | nd6_timer() at nd6_timer+0x8f | softclock() at softclock+0x2a2 | intr_event_execute_handlers() at intr_event_execute_handlers+0x66 | ithread_loop() at ithread_loop+0x8e | fork_exit() at fork_exit+0x112 | fork_trampoline() at fork_trampoline+0xe | --- trap 0, rip =3D 0, rsp =3D 0xffffff8000043d30, rbp =3D 0 --- | Uptime: 5d4h44m38s | Fatal trap 12: page fault while in kernel mode | cpuid =3D 1; apic id =3D 02 | fault virtual address =3D 0x3e0 | fault code =3D supervisor write data, page not present | instruction pointer =3D 0x20:0xffffffff8050d37d | stack pointer =3D 0x28:0xffffff80001cc510 | frame pointer =3D 0x28:0xffffff80001cc530 | code segment =3D base 0x0, limit 0xfffff, type 0x1b | =3D DPL 0, pres 1, long 1, def32 0, gran 1 | processor eflags =3D interrupt enabled, resume, IOPL =3D 0 | current process =3D 1410 (ping6) | trap number =3D 12 | panic: page fault | cpuid =3D 1 | KDB: stack backtrace: | db_trace_self_wrapper() at db_trace_self_wrapper+0x2a | panic() at panic+0x182 | trap_fatal() at trap_fatal+0x2ad | trap_pfault() at trap_pfault+0x22d | trap() at trap+0x369 | calltrap() at calltrap+0x8 | --- trap 0xc, rip =3D 0xffffffff8050d37d, rsp =3D 0xffffff80001cc510, rbp= =3D 0xffffff80001cc530 --- | _rw_wlock() at _rw_wlock+0x1d | in6_setscope() at in6_setscope+0x40 | in6_selectsrc() at in6_selectsrc+0x36e | rip6_output() at rip6_output+0x26a | rip6_send() at rip6_send+0x11e | sosend_generic() at sosend_generic+0x347 | kern_sendit() at kern_sendit+0x1a5 | sendit() at sendit+0xdc | sendmsg() at sendmsg+0x87 | syscall() at syscall+0x12b | Xfast_syscall() at Xfast_syscall+0xe1 | --- syscall (28, FreeBSD ELF64, sendmsg), rip =3D 0x800a5b64c, rsp =3D 0x= 7fffffffe5e8, rbp =3D 0x10 --- | Uptime: 4m24s Please let me know if there's any more information I can provide and/or whether I should get this into a PR. Thanks, --=20 Chris Cowart Lead Network Engineer BitGravity, Inc. A subsidiary of Tata Communications, Ltd. --+g7M9IMkV8truYOl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (Darwin) iQIcBAEBAgAGBQJPmJrdAAoJELel3ONI9pMK8rcP/jrXNVC/HVV6Jrj4YI5Ayso3 BD3KRVoX8F87uv56gNjsv+wvKFCt2jxrmJCaNUpUB+a6lzUTSJfPu+Skwo5WZFxB tk5oVCQ4noQy4vZF2KyWoYRNxocsfjGZAVANVDIUfTS3oRe2lJR2hh1LNJKJA11E PekiIshaKdoamZNMegQbBBm2Yu9zzCG/tXZZXLvlao+/Cegkb97Do+pu6KoAgwRo V5aNvzCuv/LvEQ2p4JW9R+Z8qmLrTKQamGeiPNOEcCsk5Dq947a0HPs79KqkfCnT VhPYL/qmHfahDqppL2zcplMnC8Hqu34eQSemEm5oIHHeTnMp6Q32WF5098Z3/RwS k7CHnYKLmx9bC03MfBxBt7nbY4EnQqd8mQRAq9HwMy6brEciN5yAZeP/O9ZtTuV/ pLKNopQBdWKh3T/nbcc64PTUIa3hJcHn/GzLwReVUzPH1likVV4pZpgOnP3qQLWz IoVWeWq2/hCQpsMk9MGFpPGoy2IEh2jGlK2M2Lvarbg6qpTIGWxClYj/xbsYj7FQ jKCKmEm0DQMraehoXHBQ1NLvdIDgzKm+BErZ7bf5NRGi2bykZaHiANX2Q/7MMh2s hP7pY2w/5z5WoWNKu7pKh+kb4zT7UkazhN4Q+KW2RlVyhqOkmMi55dVYl2ZfwYQ2 xCyhzm4kDXMaij484wR2 =ejxn -----END PGP SIGNATURE----- --+g7M9IMkV8truYOl-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 26 11:23:21 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 998C9106566C for ; Thu, 26 Apr 2012 11:23:21 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 29B458FC0A for ; Thu, 26 Apr 2012 11:23:20 +0000 (UTC) Received: by weyt57 with SMTP id t57so868890wey.13 for ; Thu, 26 Apr 2012 04:23:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=GW/iwa6VpiFA7fGTEXY6PvZaF/TbHGg0Y48IOMj7gD4=; b=Hvng1dQmEu6TwoI4/7boVnfSrTg4XTkoJBcvYuTgLhIIIreu2xzIvoXDjD4r26wqfy A1jytTXJupttXMHfOxFvLQVyyv6wQAEUATYkdAD0aIKRu1OMXAPy9qDlmTSFh2k0qi92 FnEaEJHUUmR6/HMMGwYH0mdH9BnnTkyLW4gGnm+/ocz5jfHlzVIYE9jgLynC3+luslej 37RbYh+mR5gk9kLt8ehdDat8S0zc5aqyvoKqeObTKm3m2jmvn4+lvpgzuqQQZ5BPM74S y7lKt8CzZFElo/qdaxYcskqZusFpFbwtAd6jfI6058TXG/4CnDTl56duyBRMv7lgZXsy 7i2A== MIME-Version: 1.0 Received: by 10.180.81.166 with SMTP id b6mr50342131wiy.0.1335439400097; Thu, 26 Apr 2012 04:23:20 -0700 (PDT) Received: by 10.180.80.230 with HTTP; Thu, 26 Apr 2012 04:23:19 -0700 (PDT) X-Originating-IP: [95.108.170.198] Date: Thu, 26 Apr 2012 15:23:19 +0400 Message-ID: From: Andrey Zonov To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary=f46d0442811e0fd8b804be9337ae X-Gm-Message-State: ALoCoQnzj0BZPDPlc09qUmF4tl42TZjiiI329nhG87fNUdYsa1n71KzUNUwjxd4MseNZ1/JPd542 Cc: davidch@freebsd.org Subject: bce: jumbo not working since r218423 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, 26 Apr 2012 11:23:21 -0000 --f46d0442811e0fd8b804be9337ae Content-Type: text/plain; charset=ISO-8859-1 Hi, I found that jumbo frames don't work after r218423 with bce driver. This happens because controller doesn't do reinitialization when MTU is changed. Attached patch solves this problem. I also don't understand why sysctl hw.bce.loose_rx_mtu doesn't respect with tunnable hw.bce.strict_rx_mtu. Is there any reason to give them different names? -- Andrey Zonov --f46d0442811e0fd8b804be9337ae Content-Type: application/octet-stream; name="if_bce.c.patch" Content-Disposition: attachment; filename="if_bce.c.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h1hp1r1c0 SW5kZXg6IHN5cy9kZXYvYmNlL2lmX2JjZS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYvYmNlL2lm X2JjZS5jCShyZXZpc2lvbiAyMzQ2MDApCisrKyBzeXMvZGV2L2JjZS9pZl9iY2UuYwkod29ya2lu ZyBjb3B5KQpAQCAtNzQxNSw3ICs3NDE1LDcgQEAKIAlzdHJ1Y3QgYmNlX3NvZnRjICpzYyA9IGlm cC0+aWZfc29mdGM7CiAJc3RydWN0IGlmcmVxICppZnIgPSAoc3RydWN0IGlmcmVxICopIGRhdGE7 CiAJc3RydWN0IG1paV9kYXRhICptaWk7Ci0JaW50IG1hc2ssIGVycm9yID0gMDsKKwlpbnQgbWFz aywgZXJyb3IgPSAwLCByZWluaXQgPSAwOwogCiAJREJFTlRFUihCQ0VfVkVSQk9TRV9NSVNDKTsK IApAQCAtNzQzNiwyMSArNzQzNiwxOSBAQAogCiAJCUJDRV9MT0NLKHNjKTsKIAkJaWZwLT5pZl9t dHUgPSBpZnItPmlmcl9tdHU7CisJCWlmIChpZnAtPmlmX2Rydl9mbGFncyAmIElGRl9EUlZfUlVO TklORykgeworCQkJLyoKKwkJCSAqIEl0IG1heSBiZSByZXF1ZXN0ZWQgdG8gdHVybiBvbi9vZmYg anVtYm8KKwkJCSAqIGZyYW1lcywgc28gcmVpbml0IGNvbnRyb2xsZXIuCisJCQkgKi8KKwkJCWJj ZV9zdG9wKHNjKTsKKwkJCXJlaW5pdCA9IDE7CisJCX0KIAotCQlpZiAoYmNlX2hkcl9zcGxpdCA9 PSBGQUxTRSkgewotCQkJaWYgKGlmcC0+aWZfZHJ2X2ZsYWdzICYgSUZGX0RSVl9SVU5OSU5HKSB7 Ci0JCQkJLyoKLQkJCQkgKiBCZWNhdXNlIGFsbG9jYXRpb24gc2l6ZSBpcyB1c2VkIGluIFJYCi0J CQkJICogYnVmZmVyIGFsbG9jYXRpb24sIHN0b3AgY29udHJvbGxlciBpZgotCQkJCSAqIGl0IGlz IGFscmVhZHkgcnVubmluZy4KLQkJCQkgKi8KLQkJCQliY2Vfc3RvcChzYyk7Ci0JCQl9Ci0KKwkJ aWYgKGJjZV9oZHJfc3BsaXQgPT0gRkFMU0UpCiAJCQliY2VfZ2V0X3J4X2J1ZmZlcl9zaXplcyhz YywgaWZwLT5pZl9tdHUpOwotCisJCWlmIChyZWluaXQpCiAJCQliY2VfaW5pdF9sb2NrZWQoc2Mp OwotCQl9CiAKIAkJQkNFX1VOTE9DSyhzYyk7CiAJCWJyZWFrOwo= --f46d0442811e0fd8b804be9337ae-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 26 13:41:04 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 B17AA106566B for ; Thu, 26 Apr 2012 13:41:04 +0000 (UTC) (envelope-from satishkamara@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2EA8D8FC0A for ; Thu, 26 Apr 2012 13:41:03 +0000 (UTC) Received: by mail-lpp01m010-f54.google.com with SMTP id v3so1226133lag.13 for ; Thu, 26 Apr 2012 06:41: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=gVXAiUWOVIFcPAI/1pIxsj1azFnm7/omkAoXoNJW6bE=; b=hKgGfb/SX8k72JWRMoWSVw5WsjjGgOgM2B8GPWIJ6APBZ3aN4j3q4iamCWOcN9gR25 X3gXDdH96FeFLYgpVpb3rQyRNTA3lxCUCgjFu9lW6V5oe/phO8CZPoMWZ7O1JlJQ4EP+ eGmypyHNvPwjJ5wtZeTq4yr6hp3dpnwBwwaTHw5ca4wUz83Lkph5u/PzB4UNbm5P40/A 2B1pp9KhPuYHgMT/BsSDSZS9deNbLkcurJ96tXklQhrkyUJlBWafaWg7nXGAZ5EMAhVh NCTepXWsHYCGgjauRevhgr7IHMrY1JFUPO8ZOwY8TwT1TspSpVf6GUFMNquwwtjPQJEp 2UTg== MIME-Version: 1.0 Received: by 10.152.145.169 with SMTP id sv9mr1461000lab.12.1335447193409; Thu, 26 Apr 2012 06:33:13 -0700 (PDT) Received: by 10.112.128.197 with HTTP; Thu, 26 Apr 2012 06:33:13 -0700 (PDT) In-Reply-To: <20120425042052.GA29615@DataIX.net> References: <20120425042052.GA29615@DataIX.net> Date: Thu, 26 Apr 2012 09:33:13 -0400 Message-ID: From: satish amara To: Jason Hellenthal Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: LLA (Link local address) in FreeBSD route command 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, 26 Apr 2012 13:41:04 -0000 I gave reference to old man page because it talks about scope which is related to link local address of IPV6. I don't see the latest man page talks about link-local address of IPV6. So I am looking for how routes for link-local address are handled in latest BSD Stack. I see some configurations where people are giving link-local address as gateway. So I am trying to see whether these configuration are valid and if not there could be bug. If BSD allows to configure routes for link local address of IPV6 then I think it could be bug as they are local to subnet and typically there routes are automatic. I am not sure allowing link-local address as gateway address is valid or not for IPV6. Thanks, Satish K Amara On Wed, Apr 25, 2012 at 12:20 AM, Jason Hellenthal wrote: > > First off lets start by referencing something that is correct and > staying within-band instead of OOB. > > http://www.freebsd.org/cgi/man.cgi?query=route > > Review that page and if you still have any questions then please ask > again. > > On Tue, Apr 24, 2012 at 05:07:54PM -0400, satish amara wrote: > > Hi, > > > > I am trying to see what is valid and is supported in latest > > FreeBSD > > > > Does BSD let user add routes to LLA destinations? > > > > Does BSD let user specify LLA gateway without specifying the scope? > > > > > > I see following man page which talks about scope but looks like it not > > supported in the latest. > > > > http://www.manpagez.com/man/8/route/ > > > > > > Thanks, > > > > Satish K Amara > > _______________________________________________ > > 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" > > -- > > - (2^(N-1)) > From owner-freebsd-net@FreeBSD.ORG Thu Apr 26 14:03:20 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 EE515106564A for ; Thu, 26 Apr 2012 14:03:20 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 6C7D58FC1B for ; Thu, 26 Apr 2012 14:03:20 +0000 (UTC) Received: by wibhq7 with SMTP id hq7so1005075wib.13 for ; Thu, 26 Apr 2012 07:03:19 -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=vFmLQfOWVhuPLm9yvlzJuF49BJLaHwmV+Wm9lsae2r8=; b=fr83pOfWV9C2UI16dX7P1Tn2pYvhNPzYd/6t7M0NIsBkL2VtzSqJiqX1ne7ErwLRyl XSJnHBqoXoQE2fFOwHtauEY5tojGA/QlvjSR6fHA6ig6Z4zOyJL+wc9339iidr59IDT5 vyxE5xYbXJIKaPUdlZE2CxvFot3zIrxrprY0TTT4EJADRX8ZH4CNm7b2/J5Nf1PueB/6 rEcl7jJfzbyKRz3m/AyJBVHRSeKLmAlU95ywInqGDcNZYIIn7A8a3cSjGVAbLj3/SA31 dGMMo9oja+3SDMLKL1CR7mhz/d/pyRttfFHgKYxrtKJpgN1FXyjpfXKa51NP8oB3zzRY +aFw== MIME-Version: 1.0 Received: by 10.180.103.35 with SMTP id ft3mr16913899wib.0.1335448999311; Thu, 26 Apr 2012 07:03:19 -0700 (PDT) Received: by 10.180.85.71 with HTTP; Thu, 26 Apr 2012 07:03:19 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Apr 2012 10:03:19 -0400 Message-ID: From: Ryan Stone To: "Li, Qing" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net Subject: Re: Removing an IPv6 address does not remove NDP entries on that subnet 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, 26 Apr 2012 14:03:21 -0000 On Wed, Apr 25, 2012 at 3:59 AM, Li, Qing wrote: > The patch is located at > > =A0 http://people.freebsd.org/~qingli/nd6_prefix.diff > > Please give it a try. I did only basic testing as of now and > will do more tomorrow. > > --Qing I tested this last night. Unfortunately this seems to be vulnerable to the same races as our current ARP implementation. First, there is a race between in6_lltable_lookup and in6_lltable_prefix_free. Here is a crash that I reproduced last night: Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x360 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff808731a2 stack pointer =3D 0x28:0xffffff80003ea280 frame pointer =3D 0x28:0xffffff80003ea320 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 22170 (nc) trap number =3D 12 panic: page fault cpuid =3D 0 Uptime: 1h10m28s Dumping 108 out of 489 MB:..15%..30%..45%..60%..74%..89% #0 doadump (textdump=3D1) at /usr/home/rstone/freebsd/head/sys/kern/kern_shutdown.c:268 268 if (textdump && textdump_pending) { (kgdb) #0 doadump (textdump=3D1) at /usr/home/rstone/freebsd/head/sys/kern/kern_shutdown.c:268 #1 0xffffffff808753b9 in kern_reboot (howto=3D260) at /usr/home/rstone/freebsd/head/sys/kern/kern_shutdown.c:454 #2 0xffffffff80874dea in panic (fmt=3D0x0) at /usr/home/rstone/freebsd/head/sys/kern/kern_shutdown.c:642 #3 0xffffffff80b72860 in trap_fatal (frame=3D0xc, eva=3DVariable "eva" is = not avail able. ) at /usr/home/rstone/freebsd/head/sys/amd64/amd64/trap.c:852 #4 0xffffffff80b72a2a in trap_pfault (frame=3D0xffffff80003ea1d0, usermode= =3D0) at /usr/home/rstone/freebsd/head/sys/amd64/amd64/trap.c:769 #5 0xffffffff80b731ea in trap (frame=3D0xffffff80003ea1d0) at /usr/home/rstone/freebsd/head/sys/amd64/amd64/trap.c:456 #6 0xffffffff80b5d7c3 in calltrap () at /usr/home/rstone/freebsd/head/sys/amd64/amd64/exception.S:228 #7 0xffffffff808731a2 in _rw_rlock (rw=3D0xfffffe00058f3410, file=3D0xffffffff80df7e40 "/usr/home/rstone/freebsd/head/sys/netinet6/i= n6.c", line=3D2615) at /usr/home/rstone/freebsd/head/sys/kern/kern_rwlock.c:388 #8 0xffffffff80a27bd9 in in6_lltable_lookup (llt=3D0xfffffe0002422600, flags=3D0, l3addr=3D0xffffff80003ea6ec) at /usr/home/rstone/freebsd/head/sys/netinet6/in6.c:2615 #9 0xffffffff80a409c6 in nd6_storelladdr (ifp=3D0xfffffe000241f000, m=3D0xfffffe000503d500, dst=3D0xffffff80003ea6ec, desten=3D0xffffff80003ea430 "\xc0\230\b\005", lle=3D0xffffff80003ea428) #10 0xffffffff80936f24 in ether_output (ifp=3D0xfffffe000241f000, m=3D0xfffffe000503d500, dst=3D0xffffff80003ea6ec, ro=3DVariable "ro" is= not availa ble. ) at /usr/home/rstone/freebsd/head/sys/net/if_ethersubr.c:235 #11 0xffffffff80a417df in nd6_output_lle (ifp=3D0xfffffe000241f000, origifp=3D0xfffffe000241f000, m0=3D0xfffffe000503d500, dst=3D0xffffff80003ea6ec, rt0=3DVariable "rt0" is not available. ) at /usr/home/rstone/freebsd/head/sys/netinet6/nd6.c:2081 #12 0xffffffff80a41a18 in nd6_output (ifp=3DVariable "ifp" is not available= . ) at /usr/home/rstone/freebsd/head/sys/netinet6/nd6.c:1828 #13 0xffffffff80a3c400 in ip6_output (m0=3D0x0, opt=3DVariable "opt" is not available.) at /usr/home/rstone/freebsd/head/sys/netinet6/ip6_output.c:1123 #14 0xffffffff80a4debe in udp6_send (so=3DVariable "so" is not available. ) at /usr/home/rstone/freebsd/head/sys/netinet6/udp6_usrreq.c:782 #15 0xffffffff808e97de in sosend_dgram (so=3D0xfffffe00058d3d48, addr=3D0x0, uio=3DVariable "uio" is not available. at /usr/home/rstone/freebsd/head/sys/kern/uipc_socket.c:1118 #16 0xffffffff808cddad in soo_write (fp=3DVariable "fp" is not available. ) at /usr/home/rstone/freebsd/head/sys/kern/sys_socket.c:102 #17 0xffffffff808c5f25 in dofilewrite (td=3D0xfffffe00050898c0, fd=3D3, fp=3D0xfffffe0005134000, auio=3D0xffffff80003eaad0, offset=3DVariable "= offset" is not available. ) at file.h:271 #18 0xffffffff808c65ac in kern_writev (td=3D0xfffffe00050898c0, fd=3D3, auio=3D0xffffff80003eaad0) at /usr/home/rstone/freebsd/head/sys/kern/sys_generic.c:459 #19 0xffffffff808c66c4 in sys_write (td=3DVariable "td" is not available. ) at /usr/home/rstone/freebsd/head/sys/kern/sys_generic.c:375 #20 0xffffffff80b71f79 in amd64_syscall (td=3D0xfffffe00050898c0, traced=3D= 0) at subr_syscall.c:135 #21 0xffffffff80b5daa7 in Xfast_syscall () at /usr/home/rstone/freebsd/head/sys/amd64/amd64/exception.S:387 The line in in6_lltable_lookup that it crashes at (in6.c:2615) is the LLE_RLOCK at the end of the function. From the vmcore I can see that the lle was destroyed: (kgdb) print *lle $1 =3D {lle_next =3D {le_next =3D 0xdeadc0dedeadc0de, le_prev =3D 0xdeadc0d= edeadc0de}, lle_lock =3D {lock_object =3D { lo_name =3D 0xdeadc0dedeadc0de
, lo_flags =3D 3735929054, lo_data =3D 3735929054, lo_witness =3D 0xdeadc0dedeadc0de}, rw_lock =3D 16045693110842147038}= , lle_tbl =3D 0xdeadc0dedeadc0de, lle_head =3D 0xdeadc0dedeadc0de, lle_free =3D 0xdeadc0dedeadc0de, la_hold =3D 0xdeadc0dedeadc0de, la_numheld =3D -559038242, la_expire =3D -2401050962867404578, la_flags = =3D 49374, la_asked =3D 57005, la_preempt =3D 49374, ln_byhint =3D 57005, ln_state = =3D -16162, ln_router =3D 57005, ln_ntick =3D -2401050962867404578, lle_refcnt =3D -5= 59038242, ll_addr =3D {mac_aligned =3D 16045693110842147038, mac16 =3D {49374, 5700= 5, 49374}}, lle_timer =3D {ln_timer_ch =3D {c_links =3D {sle =3D { sle_next =3D 0xdeadc0dedeadc0de}, tqe =3D { tqe_next =3D 0xdeadc0dedeadc0de, tqe_prev =3D 0xdeadc0dedeadc0de}= }, c_time =3D -559038242, c_arg =3D 0xdeadc0dedeadc0de, c_func =3D 0xdeadc0dedeadc0de, c_lock =3D 0xdeadc0dedeadc0de, c_flags =3D -559038242, c_cpu =3D -559038242}, la_timer =3D {c_links = =3D {sle =3D { sle_next =3D 0xdeadc0dedeadc0de}, tqe =3D { tqe_next =3D 0xdeadc0dedeadc0de, tqe_prev =3D 0xdeadc0dedeadc0de}= }, c_time =3D -559038242, c_arg =3D 0xdeadc0dedeadc0de, c_func =3D 0xdeadc0dedeadc0de, c_lock =3D 0xdeadc0dedeadc0de, c_flags =3D -559038242, c_cpu =3D -559038242}}} The test that I was running was I had one ping6 -f going to an IPv6 address as well as a loop of nc -u. In another terminal I had a script constantly removing and adding the ipv6 address from which I was pinging/ncing. I haven't looked at the netinet6 code too closely yet but if it follows the netinet implementation in6_lltable_prefix_free should acquire the afdata_lock on the ifp before touching the lltable. I haven't tried a test for this yet, but I also believe that in6_lltable_prefix_free also doesn't drain the callout in the llentry correctly. I try testing this to confirm this now. From owner-freebsd-net@FreeBSD.ORG Thu Apr 26 14:17:12 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 A1AE7106566B for ; Thu, 26 Apr 2012 14:17:12 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from plsvl-mailgw-02.bluecoat.com (plsvl-mailgw-02.bluecoat.com [199.91.133.12]) by mx1.freebsd.org (Postfix) with ESMTP id 75E818FC14 for ; Thu, 26 Apr 2012 14:17:12 +0000 (UTC) Received: from PWSVL-EXCHTS-02.internal.cacheflow.com (unknown [10.2.2.126]) by plsvl-mailgw-02.bluecoat.com (Postfix) with ESMTP id AA7C3200F3; Thu, 26 Apr 2012 07:10:28 -0700 (PDT) Received: from pwsvl-excmbx-05.internal.cacheflow.com ([fe80::f848:d461:9aa9:59a8]) by PWSVL-EXCHTS-02.internal.cacheflow.com ([fe80::4910:317f:407:6ecc%14]) with mapi id 14.01.0289.001; Thu, 26 Apr 2012 07:08:41 -0700 From: "Li, Qing" To: Ryan Stone Thread-Topic: Removing an IPv6 address does not remove NDP entries on that subnet Thread-Index: AQHNI7VX+mMM66qaLkCuQ2Pu1sztrJatJJVQ Date: Thu, 26 Apr 2012 14:08:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.91.133.85] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: freebsd-net Subject: RE: Removing an IPv6 address does not remove NDP entries on that subnet 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, 26 Apr 2012 14:17:12 -0000 Okay, this is good information. I will look into it now. Thanks, --Qing > -----Original Message----- > From: Ryan Stone [mailto:rysto32@gmail.com] > Sent: Thursday, April 26, 2012 7:03 AM > To: Li, Qing > Cc: freebsd-net > Subject: Re: Removing an IPv6 address does not remove NDP entries on > that subnet >=20 > On Wed, Apr 25, 2012 at 3:59 AM, Li, Qing wrote: > > The patch is located at > > > > =A0 http://people.freebsd.org/~qingli/nd6_prefix.diff > > > > Please give it a try. I did only basic testing as of now and > > will do more tomorrow. > > > > --Qing >=20 > I tested this last night. Unfortunately this seems to be vulnerable > to the same races as our current ARP implementation. First, there is > a race between in6_lltable_lookup and in6_lltable_prefix_free. Here > is a crash that I reproduced last night: >=20 > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =3D 0x360 > fault code =3D supervisor read data, page not present > instruction pointer =3D 0x20:0xffffffff808731a2 > stack pointer =3D 0x28:0xffffff80003ea280 > frame pointer =3D 0x28:0xffffff80003ea320 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 22170 (nc) > trap number =3D 12 > panic: page fault > cpuid =3D 0 > Uptime: 1h10m28s > Dumping 108 out of 489 MB:..15%..30%..45%..60%..74%..89% >=20 > #0 doadump (textdump=3D1) > at /usr/home/rstone/freebsd/head/sys/kern/kern_shutdown.c:268 > 268 if (textdump && textdump_pending) { > (kgdb) #0 doadump (textdump=3D1) > at /usr/home/rstone/freebsd/head/sys/kern/kern_shutdown.c:268 > #1 0xffffffff808753b9 in kern_reboot (howto=3D260) > at /usr/home/rstone/freebsd/head/sys/kern/kern_shutdown.c:454 > #2 0xffffffff80874dea in panic (fmt=3D0x0) > at /usr/home/rstone/freebsd/head/sys/kern/kern_shutdown.c:642 > #3 0xffffffff80b72860 in trap_fatal (frame=3D0xc, eva=3DVariable "eva" i= s > not avail > able. > ) > at /usr/home/rstone/freebsd/head/sys/amd64/amd64/trap.c:852 > #4 0xffffffff80b72a2a in trap_pfault (frame=3D0xffffff80003ea1d0, > usermode=3D0) > at /usr/home/rstone/freebsd/head/sys/amd64/amd64/trap.c:769 > #5 0xffffffff80b731ea in trap (frame=3D0xffffff80003ea1d0) > at /usr/home/rstone/freebsd/head/sys/amd64/amd64/trap.c:456 > #6 0xffffffff80b5d7c3 in calltrap () > at /usr/home/rstone/freebsd/head/sys/amd64/amd64/exception.S:228 > #7 0xffffffff808731a2 in _rw_rlock (rw=3D0xfffffe00058f3410, > file=3D0xffffffff80df7e40 > "/usr/home/rstone/freebsd/head/sys/netinet6/in6.c", > line=3D2615) at /usr/home/rstone/freebsd/head/sys/kern/kern_rwlock.c:388 > #8 0xffffffff80a27bd9 in in6_lltable_lookup (llt=3D0xfffffe0002422600, > flags=3D0, l3addr=3D0xffffff80003ea6ec) > at /usr/home/rstone/freebsd/head/sys/netinet6/in6.c:2615 > #9 0xffffffff80a409c6 in nd6_storelladdr (ifp=3D0xfffffe000241f000, > m=3D0xfffffe000503d500, dst=3D0xffffff80003ea6ec, > desten=3D0xffffff80003ea430 "\xc0\230\b\005", lle=3D0xffffff80003ea42= 8) > #10 0xffffffff80936f24 in ether_output (ifp=3D0xfffffe000241f000, > m=3D0xfffffe000503d500, dst=3D0xffffff80003ea6ec, ro=3DVariable "ro" = is > not availa > ble. > ) > at /usr/home/rstone/freebsd/head/sys/net/if_ethersubr.c:235 > #11 0xffffffff80a417df in nd6_output_lle (ifp=3D0xfffffe000241f000, > origifp=3D0xfffffe000241f000, m0=3D0xfffffe000503d500, > dst=3D0xffffff80003ea6ec, rt0=3DVariable "rt0" is not available. > ) > at /usr/home/rstone/freebsd/head/sys/netinet6/nd6.c:2081 > #12 0xffffffff80a41a18 in nd6_output (ifp=3DVariable "ifp" is not > available. > ) > at /usr/home/rstone/freebsd/head/sys/netinet6/nd6.c:1828 > #13 0xffffffff80a3c400 in ip6_output (m0=3D0x0, opt=3DVariable "opt" is > not available.) > at /usr/home/rstone/freebsd/head/sys/netinet6/ip6_output.c:1123 > #14 0xffffffff80a4debe in udp6_send (so=3DVariable "so" is not available. > ) > at /usr/home/rstone/freebsd/head/sys/netinet6/udp6_usrreq.c:782 > #15 0xffffffff808e97de in sosend_dgram (so=3D0xfffffe00058d3d48, > addr=3D0x0, uio=3DVariable "uio" is not available. > at /usr/home/rstone/freebsd/head/sys/kern/uipc_socket.c:1118 > #16 0xffffffff808cddad in soo_write (fp=3DVariable "fp" is not available. > ) > at /usr/home/rstone/freebsd/head/sys/kern/sys_socket.c:102 > #17 0xffffffff808c5f25 in dofilewrite (td=3D0xfffffe00050898c0, fd=3D3, > fp=3D0xfffffe0005134000, auio=3D0xffffff80003eaad0, offset=3DVariable > "offset" is > not available. > ) at file.h:271 > #18 0xffffffff808c65ac in kern_writev (td=3D0xfffffe00050898c0, fd=3D3, > auio=3D0xffffff80003eaad0) > at /usr/home/rstone/freebsd/head/sys/kern/sys_generic.c:459 > #19 0xffffffff808c66c4 in sys_write (td=3DVariable "td" is not available. > ) > at /usr/home/rstone/freebsd/head/sys/kern/sys_generic.c:375 > #20 0xffffffff80b71f79 in amd64_syscall (td=3D0xfffffe00050898c0, > traced=3D0) > at subr_syscall.c:135 > #21 0xffffffff80b5daa7 in Xfast_syscall () > at /usr/home/rstone/freebsd/head/sys/amd64/amd64/exception.S:387 >=20 > The line in in6_lltable_lookup that it crashes at (in6.c:2615) is the > LLE_RLOCK at the end of the function. From the vmcore I can see that > the lle was destroyed: >=20 > (kgdb) print *lle > $1 =3D {lle_next =3D {le_next =3D 0xdeadc0dedeadc0de, le_prev =3D > 0xdeadc0dedeadc0de}, > lle_lock =3D {lock_object =3D { > lo_name =3D 0xdeadc0dedeadc0de
bounds>, > lo_flags =3D 3735929054, lo_data =3D 3735929054, > lo_witness =3D 0xdeadc0dedeadc0de}, rw_lock =3D 1604569311084214703= 8}, > lle_tbl =3D 0xdeadc0dedeadc0de, lle_head =3D 0xdeadc0dedeadc0de, > lle_free =3D 0xdeadc0dedeadc0de, la_hold =3D 0xdeadc0dedeadc0de, > la_numheld =3D -559038242, la_expire =3D -2401050962867404578, la_flags= =3D > 49374, > la_asked =3D 57005, la_preempt =3D 49374, ln_byhint =3D 57005, ln_state= =3D - > 16162, > ln_router =3D 57005, ln_ntick =3D -2401050962867404578, lle_refcnt =3D = - > 559038242, > ll_addr =3D {mac_aligned =3D 16045693110842147038, mac16 =3D {49374, 57= 005, > 49374}}, lle_timer =3D {ln_timer_ch =3D {c_links =3D {sle =3D { > sle_next =3D 0xdeadc0dedeadc0de}, tqe =3D { > tqe_next =3D 0xdeadc0dedeadc0de, tqe_prev =3D > 0xdeadc0dedeadc0de}}, > c_time =3D -559038242, c_arg =3D 0xdeadc0dedeadc0de, > c_func =3D 0xdeadc0dedeadc0de, c_lock =3D 0xdeadc0dedeadc0de, > c_flags =3D -559038242, c_cpu =3D -559038242}, la_timer =3D {c_link= s =3D > {sle =3D { > sle_next =3D 0xdeadc0dedeadc0de}, tqe =3D { > tqe_next =3D 0xdeadc0dedeadc0de, tqe_prev =3D > 0xdeadc0dedeadc0de}}, > c_time =3D -559038242, c_arg =3D 0xdeadc0dedeadc0de, > c_func =3D 0xdeadc0dedeadc0de, c_lock =3D 0xdeadc0dedeadc0de, > c_flags =3D -559038242, c_cpu =3D -559038242}}} >=20 >=20 > The test that I was running was I had one ping6 -f going to an IPv6 > address as well as a loop of nc -u. In another terminal I had a > script constantly removing and adding the ipv6 address from which I > was pinging/ncing. >=20 > I haven't looked at the netinet6 code too closely yet but if it > follows the netinet implementation in6_lltable_prefix_free should > acquire the afdata_lock on the ifp before touching the lltable. >=20 >=20 > I haven't tried a test for this yet, but I also believe that > in6_lltable_prefix_free also doesn't drain the callout in the llentry > correctly. I try testing this to confirm this now. From owner-freebsd-net@FreeBSD.ORG Thu Apr 26 18:07:41 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 C147D106566B; Thu, 26 Apr 2012 18:07:41 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 7A93E8FC0A; Thu, 26 Apr 2012 18:07:41 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q3QI7NVf055615; Thu, 26 Apr 2012 11:07:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1335463644; bh=nRhzhOfLbaXPsy0y7PvjssMCCY4rJUgnc9ccPeMABqw=; h=Subject:From:To:Cc:Content-Type:Date:Message-ID:Mime-Version: Content-Transfer-Encoding; b=cLlhCeFSjxsFXZlVD/8Q8mytrC0Kpx0Fr/z0siFfsLa81YyMNnB+p5YJt/B0DYBKp BHinwLXviMaBMozv3JTtYwZsHs+1GJp77hZSQGdoIBLtxPEbOFE3luC7vqLndX3aTB 8P/rALxCxPKhlErIAq5pvAmw6OijS7//qm9axhl4= From: Sean Bruno To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset="UTF-8" Date: Thu, 26 Apr 2012 11:07:23 -0700 Message-ID: <1335463643.2727.10.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 463643002 Cc: Jack Vogel , John Baldwin Subject: igb(4) at peak in big purple 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, 26 Apr 2012 18:07:41 -0000 8 core box with 2 igb(4) interfaces serving internet traffic in/out over here in Yahoo land. This is configuring igb(4) allow 32k TXD/RXD descriptors(but only configuring for 8k), 4 queues per interface and changing the logic of the call to bus_bind_intr() such that it will iterate over all cpus in the system: http://people.freebsd.org/~sbruno/if_igb.c.txt http://people.freebsd.org/~sbruno/igb_stats.txt We're seeing >100MB/s which is very nice. Thanks! I note form top that igb0 queue 0 is always "more busy" than any other queue, there appears to be a second kernel igb0 "queue" process/thread that appears to be moderately busy and 3 kernel igb0 "queue" processes/threads that appear to be doing nothing in particular. There are not causing issues ... I'm just curious if this is meaningful to anyone or indicative of interesting things. Sean From owner-freebsd-net@FreeBSD.ORG Thu Apr 26 18:14:17 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 D572A106564A for ; Thu, 26 Apr 2012 18:14:17 +0000 (UTC) (envelope-from juli@clockworksquid.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 5D3A48FC14 for ; Thu, 26 Apr 2012 18:14:17 +0000 (UTC) Received: by weyt57 with SMTP id t57so1193366wey.13 for ; Thu, 26 Apr 2012 11:14:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=gP9b3XOZj/hvBYqrQv1cvCcxFb+mSlnqtmN3iMZC+Nc=; b=eI5f7WgXenSMVwK0YX5RbfNDlsSLswzSnk2Gl0ewtT4MCKBWolfmgQuugKv7pyiCMo y8lkwv1ZmH/r/yRm2twAS49dyNF8PcMAlB1r3gG3ApLlIO0nppuhqAHMNUyiBB/w2+TW M3NYhIDx4UkiUm1/T+4JS+t1QJs/cN59pDAo8W+D3tVnG1EjNa/Tu7IxfkXXo58HgXVD s0DtmD8IT4s+Oes7hV+neYBCMPjIb+kjBcGkTjXslGSaOgSk05Q5xEjGEM60Pybn+DEG Xf6qURgvBAZddygWK2Ce2guuOhIAxij/l3VmemOURcpt2+HBhRiK/Cn0j9IBjSUnRaQB iMsA== Received: by 10.180.94.161 with SMTP id dd1mr16137444wib.16.1335464056210; Thu, 26 Apr 2012 11:14:16 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.216.110.67 with HTTP; Thu, 26 Apr 2012 11:13:55 -0700 (PDT) In-Reply-To: <1335463643.2727.10.camel@powernoodle-l7.corp.yahoo.com> References: <1335463643.2727.10.camel@powernoodle-l7.corp.yahoo.com> From: Juli Mallett Date: Thu, 26 Apr 2012 11:13:55 -0700 X-Google-Sender-Auth: FohBmk8mpRi9NlySaqOpmzmZvKQ Message-ID: To: Sean Bruno Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnrTdCz1ZC7wNMdlYbG8176HLNd1ZPmZISmP9vZIxrAmwlITPGIobr3n+X12HnwXN2nTo7P Cc: "freebsd-net@freebsd.org" Subject: Re: igb(4) at peak in big purple 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, 26 Apr 2012 18:14:17 -0000 On Thu, Apr 26, 2012 at 11:07, Sean Bruno wrote: > I note form top that igb0 queue 0 is always "more busy" than any other > queue, there appears to be a second kernel igb0 "queue" process/thread > that appears to be moderately busy and 3 kernel igb0 "queue" > processes/threads that appear to be doing nothing in particular. Queue splitting in Intel cards is done using a hash of protocol headers, so this is expected behavior. This also helps with TCP and UDP performance, in terms of keeping packets for the same protocol control block on the same core, but for other applications it's not ideal. If your application does not require that kind of locality, there are things that can be done in the driver to make it easier to balance packets between all queues about-evenly. I've also seen it be the case that some cores will use more CPU time for reasons of unusually-slow memory access from that core, i.e. with non-uniform memory, or with some CPU threads, rather than because more packets are going to a queue. It would certainly be very nice at some point for netstat -I to grow awareness of multiple queues (which is a bit non-trivial because of how those statistics are gathered from struct ifnet) so that one could more easily watch in real time the packet rate to each queue. Probably someone with more patience than me could do this using the sysctl nodes the drivers export. Juli. From owner-freebsd-net@FreeBSD.ORG Thu Apr 26 21:06: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 1E401106566C for ; Thu, 26 Apr 2012 21:06:40 +0000 (UTC) (envelope-from prabhakar.lakhera@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id CE7268FC15 for ; Thu, 26 Apr 2012 21:06:39 +0000 (UTC) Received: by yhgm50 with SMTP id m50so58187yhg.13 for ; Thu, 26 Apr 2012 14:06:39 -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=HOzv2x0/4P1JHWFB+imayPTdugOwVQ6FT+6IbkZPcwU=; b=m1Ju8qtosZZ8blqlA/emFq1zp+CgM2kMvWYhSS7kc3aNvjXGmlbryE3CG01ya0FYt0 5Di6UFx/sWI0B27QC4aBoeEnew9LlrFEXZ/RzNiG+aOmDcZ3n9mqGIS3RgHOSrfntr8A 3jZ19SlsNtNA5CZhkImG94FYuRnbYfyeiuqRuU5cpMgsxyYiVs/Jzv0qVm6z6KuEiGuZ N5M8H7bMGsygiKZYPoMQ4PoXRRUFIpUcKNdbJHFy5u7IF28PqAWo4698UCnr4xZOz/iv oqFYZ5JwWpnhJNVG87SNTPIuops1RSO37HFe5CjHneIbNyy3lSGNTjkA8KSzOnpTeLin lREw== MIME-Version: 1.0 Received: by 10.236.136.198 with SMTP id w46mr8186841yhi.68.1335474399393; Thu, 26 Apr 2012 14:06:39 -0700 (PDT) Received: by 10.100.147.8 with HTTP; Thu, 26 Apr 2012 14:06:39 -0700 (PDT) Date: Thu, 26 Apr 2012 14:06:39 -0700 Message-ID: From: prabhakar lakhera To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: About static route retargetting in IPv6 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, 26 Apr 2012 21:06:40 -0000 Hi, In RFC 4861 Section: 8.1. Validation of Redirect Messageswe have the following bullets: A host *MUST *silently discard any received Redirect message that does not satisfy all of the following validity checks: - IP Source Address is a link-local address. Routers *MUST *use their link-local address as the source for Router Advertisement and Redirect messages so that hosts can uniquely identify routers. ... ... - The IP source address of the Redirect is the same as the current first-hop router for the specified ICMP Destination Address. The above two bullets implicitly imply that the gateways installed in routing tables MUST have LLA scope only for the node to be able to process redirects. For static routes when ifa gets deleted or when a port goes down, routes get re-targeted. For static indirect routes we look for other ifa in the same subnet or with same prefix as gateway's ifa. For subnet routes the existing ones are re-targeted to a different ifa/ifp when possible. I believe the existing dynamic routes (cloned ones) are purged and are learned again when required. For IPv6 dynamically learned default router we have default router selection which gets triggered from various events (neighbor cache entry for gateway expiring, RA received which implies router is not more valid, NA received for a neighbor that was considered to be a router, port configured down/link down etc etc). That is responsible for installing new default route when required. We have an option to disabled RA processing. User then has to install static default routes. When user does that in order to process redirects user MUST add indirect static routes with LLA scoped addresses. Also default router selection mechanism would not work for these default route entries (since defrouter list does not include static routers). The question is how do we re-target these routes? The route re-targeting mechanisms in place a based on prefix comparison. Currently LLA addresses can get auto-configured since they are well defined (fe80) and don't depend on learning prefixes via received RAs. However they are currently all limited to the interface they are configured on. Has there been any effort to dynamically learn what local ports are on-link and using that information to embed the scope in the LLA rather than interface ids? That would help in getting these static default routes ,with LLA gateways, re-targeted. If people are already working on it, I would appreciate if they could comment on it and get in touch. Best, Prabhakar From owner-freebsd-net@FreeBSD.ORG Thu Apr 26 23:03: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 9C01F106566B for ; Thu, 26 Apr 2012 23:03:17 +0000 (UTC) (envelope-from prabhakar.lakhera@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 170318FC16 for ; Thu, 26 Apr 2012 23:03:17 +0000 (UTC) Received: by yenl9 with SMTP id l9so118804yen.13 for ; Thu, 26 Apr 2012 16:03:16 -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=xgzJ1FhjYnIzJK3tDwvTTPIyLV0Oc03hX7+GJYF3S+c=; b=DduFjYPJLN28ycYvB/IUoA+S7yc29D/ksqY5ffIDj83Oo28AXpBpHl/UXccy0pzehs r511l9fU6MKtM28N7AT7lM7vsd5Bp2dFP5780qlaMA3viYILjva+k9tGO5/nynFne14S 8VO1f94QrizAr/0E860my2RkEQGqC0FQVJRmjN5G69umivErU2rHDCsDfXkN4kGVEQ0N ngl6bKJzf5p50jdZ6hSGR8P0kuRDBmsAXyouuUPHa+nigC/uw2Ifj0QVg3scuHg2B8OQ fEZRt7SVllNG3MJBSPG/9VkTIOXRFENwyv87O8+TCv+44F9Jnj1DZAq30u4m09uTpp77 Bvcw== MIME-Version: 1.0 Received: by 10.236.161.73 with SMTP id v49mr8560944yhk.89.1335481396110; Thu, 26 Apr 2012 16:03:16 -0700 (PDT) Received: by 10.100.147.8 with HTTP; Thu, 26 Apr 2012 16:03:16 -0700 (PDT) In-Reply-To: References: <20120425042052.GA29615@DataIX.net> Date: Thu, 26 Apr 2012 16:03:16 -0700 Message-ID: From: prabhakar lakhera To: satish amara Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: LLA (Link local address) in FreeBSD route command 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, 26 Apr 2012 23:03:17 -0000 comment inline: On Thu, Apr 26, 2012 at 6:33 AM, satish amara wrote: > I gave reference to old man page because it talks about scope which is > related to link local address of IPV6. > I don't see the latest man page talks about link-local address of IPV6. So > I am looking for how routes for link-local address are handled in latest > BSD Stack. > I see some configurations where people are giving link-local address > as gateway. > So I am trying to see whether these configuration are valid and if > not there could be bug. > >>>>> I meantioned this in a previous mail and in a different context but RFC 4861 seems to be mandating indirect routes with LLA gateway in order to process redirects. There's no reason why user should not be allowed to add static routes with LLA gateways (actually there's a case to not allow non LLA gateways for RFC compliance): In RFC 4861 Section: 8.1. Validation of Redirect Messages we have the following bullets: A host *MUST *silently discard any received Redirect message that does not satisfy all of the following validity checks: - IP Source Address is a link-local address. Routers *MUST *use their link-local address as the source for Router Advertisement and Redirect messages so that hosts can uniquely identify routers. ... ... - The IP source address of the Redirect is the same as the current first-hop router for the specified ICMP Destination Address. > > If BSD allows to configure routes for link local address of IPV6 then > Ithink it could be bug as they are local to subnet and typically there > routes are automatic. I am not sure allowing link-local address as gateway > address is valid or not for IPV6. > > Thanks, > Satish K Amara > > > > > On Wed, Apr 25, 2012 at 12:20 AM, Jason Hellenthal > wrote: > > > > > First off lets start by referencing something that is correct and > > staying within-band instead of OOB. > > > > http://www.freebsd.org/cgi/man.cgi?query=route > > > > Review that page and if you still have any questions then please ask > > again. > > > > On Tue, Apr 24, 2012 at 05:07:54PM -0400, satish amara wrote: > > > Hi, > > > > > > I am trying to see what is valid and is supported in latest > > > FreeBSD > > > > > > Does BSD let user add routes to LLA destinations? > > > > > > Does BSD let user specify LLA gateway without specifying the scope? > > > > > > > > > I see following man page which talks about scope but looks like it not > > > supported in the latest. > > > > > > http://www.manpagez.com/man/8/route/ > > > > > > > > > Thanks, > > > > > > Satish K Amara > > > _______________________________________________ > > > 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" > > > > -- > > > > - (2^(N-1)) > > > _______________________________________________ > 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 Fri Apr 27 06:07:29 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 8B63C106564A; Fri, 27 Apr 2012 06:07:29 +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 5EBE48FC12; Fri, 27 Apr 2012 06:07:29 +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 q3R67TQD026866; Fri, 27 Apr 2012 06:07:29 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3R67TiO026862; Fri, 27 Apr 2012 06:07:29 GMT (envelope-from linimon) Date: Fri, 27 Apr 2012 06:07:29 GMT Message-Id: <201204270607.q3R67TiO026862@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/167325: [netinet] [patch] sosend sometimes return EINVAL with TSO and VLAN on 82599 NIC 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, 27 Apr 2012 06:07:29 -0000 Old Synopsis: sosend sometimes return EINVAL with TSO and VLAN on 82599 NIC New Synopsis: [netinet] [patch] sosend sometimes return EINVAL with TSO and VLAN on 82599 NIC Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Apr 27 06:07:00 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=167325 From owner-freebsd-net@FreeBSD.ORG Fri Apr 27 07:04:11 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 2C06C106564A; Fri, 27 Apr 2012 07:04:11 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id E6F2A8FC12; Fri, 27 Apr 2012 07:04:10 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so654122pbc.13 for ; Fri, 27 Apr 2012 00:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=uCZGYWRFqeEk91najYOwbP8KtmQeuW3DCbZQ2TJXjUw=; b=WFpxIYSiCUM2oIz+TgsGMLaAJtOe1idrA+nCngObL4QYRSj1zVD2aDqgjf5gownPbp BIpAalxl+Jv9nSCfiWsMwUjfYMr8eaU6nOMSKmSI8GEBQN6YVFtWBaaqwG66nUQB2rQH epsZqbjCGhHAhhriJx6fuEQMqJ8XQ48ypO/KzM8blVCaVybt6s3UswFI3FsojtcFEQtL VwIGCsmjx73qFcdIobtkaJXN3zQfoKFQEEHgWJj1GDl44HawJfuIb0aq2hSxBD34WWk0 008DwHOPgQ214CBCIUo+DMCWK6iiUllJiizcQ4qV5ni9KwQG5fXfvYEARtXSE0bQ8xEn 4oZg== Received: by 10.68.195.164 with SMTP id if4mr7151554pbc.87.1335510250784; Fri, 27 Apr 2012 00:04:10 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id q1sm5615093pbp.62.2012.04.27.00.04.07 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Apr 2012 00:04:09 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 27 Apr 2012 16:04:00 -0700 From: YongHyeon PYUN Date: Fri, 27 Apr 2012 16:04:00 -0700 To: Andrey Zonov Message-ID: <20120427230400.GB17009@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="9zSXsLTf0vkW971A" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, davidch@freebsd.org Subject: Re: bce: jumbo not working since r218423 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 07:04:11 -0000 --9zSXsLTf0vkW971A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Apr 26, 2012 at 03:23:19PM +0400, Andrey Zonov wrote: > Hi, > > I found that jumbo frames don't work after r218423 with bce driver. > This happens because controller doesn't do reinitialization when MTU > is changed. Attached patch solves this problem. > Could you verify whether attached diff addresses the issue? Sorry, I couldn't setup my box yet due to some other reasons so the diff was not tested. > I also don't understand why sysctl hw.bce.loose_rx_mtu doesn't respect > with tunnable hw.bce.strict_rx_mtu. Is there any reason to give them > different names? > It may be an oversight. Personally I don't see any reason except debugging purpose to limit RX frame size to interface MTU. It makes sense when controller send frames but it should be able to receive any sized RX frames(if controller allows it). Dropping RX frames that are bigger than interface MTU would break path MTU discovery of remote host that uses bigger MTU. --9zSXsLTf0vkW971A Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="bce.mtu.diff" Index: sys/dev/bce/if_bce.c =================================================================== --- sys/dev/bce/if_bce.c (revision 234725) +++ sys/dev/bce/if_bce.c (working copy) @@ -6842,6 +6842,8 @@ bcopy(IF_LLADDR(sc->bce_ifp), sc->eaddr, ETHER_ADDR_LEN); bce_set_mac_addr(sc); + if (bce_hdr_split == FALSE) + bce_get_rx_buffer_sizes(sc, ifp->if_mtu); /* * Calculate and program the hardware Ethernet MTU * size. Be generous on the receive if we have room @@ -7436,22 +7438,10 @@ BCE_LOCK(sc); ifp->if_mtu = ifr->ifr_mtu; - - if (bce_hdr_split == FALSE) { - if (ifp->if_drv_flags & IFF_DRV_RUNNING) { - /* - * Because allocation size is used in RX - * buffer allocation, stop controller if - * it is already running. - */ - bce_stop(sc); - } - - bce_get_rx_buffer_sizes(sc, ifp->if_mtu); - + if (ifp->if_drv_flags & IFF_DRV_RUNNING) { + ifp->if_drv_flags &= ~IFF_DRV_RUNNING; bce_init_locked(sc); } - BCE_UNLOCK(sc); break; --9zSXsLTf0vkW971A-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 27 13:32:44 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 C178F106564A for ; Fri, 27 Apr 2012 13:32:44 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm13-vm2.bullet.mail.ne1.yahoo.com (nm13-vm2.bullet.mail.ne1.yahoo.com [98.138.91.89]) by mx1.freebsd.org (Postfix) with SMTP id 628878FC14 for ; Fri, 27 Apr 2012 13:32:44 +0000 (UTC) Received: from [98.138.90.48] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 27 Apr 2012 13:32:38 -0000 Received: from [98.138.89.244] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 27 Apr 2012 13:32:38 -0000 Received: from [127.0.0.1] by omp1058.mail.ne1.yahoo.com with NNFMP; 27 Apr 2012 13:32:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 833716.2085.bm@omp1058.mail.ne1.yahoo.com Received: (qmail 30124 invoked by uid 60001); 27 Apr 2012 13:32:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1335533558; bh=dMIS9B1K6k3As2nedaPFjGuytGe1Ga4X+6I52lrBS7k=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=X/6KgG2Ff50qCyL4e5yFLtFIbYK+v9dkvrnwv/y1utN3j4pnxYkCiPfgZ2ShJBdeEGQWZlvqWyCB7602fb9lnRCcZEvPgZfknr+yniAMc+91q3ypB/aBwyJI6ZZB4ILkIwNM7ktWypyXLXMiBOXBkVHkvdBgNumJOBD+iXEGI98= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YO6L0rJuRI/kiEKvUlQaGLjhx3r8Pr/1ZcJpZzjOEQUn5Uo3EyuQSnC0nUYCLe8QSDdrZnSXcBrt269iv6Vas+SLkJz59AOBmo9H4zQmw0OOaE41ufYQu6aA+EJJwD7D5iOpoj/kqn8glTrXivfitnP22aMz3DTyWy3QmmZZUYI=; X-YMail-OSG: tPdaCwMVM1lt.txiVhb2qTB7MW2KPil9ETdh_YgloZ.6SE2 JbW2.7tHXfiDLw.mYrG4waONFr5dCEn68o888iYOUL5Uhg3lUTHRxhuBCCoG WpE.9cHSlFIUZtKN440qYMVRxf6X809P83AGBXRF_5_U01_u.0pJ9NXeMrVA CIjxSukZsXi_eZprdEcpQ6NMdfeDhjXZnjK2IexhQTEQWIcoDT3KT98rUlAO t9RdS6Ij6jyGrHj.wIKiKMSkAMFGRnhMeJxg20Z_9tfBwQZSWvZt8Hj4XN_1 w6mPGqDWO_1XcG5JVoQw7NhuCrfCKP_Zw.uwDzSFJIE249sTm2H2WdgoDWb_ JYri7R5uU3MKzvIMNRKk7OYaEtZ4vTbJpIZ8oS65ZQecUhNrQKeH7nS7q5sI 3kWgBVFu3F7xDSCuEJ9UrSFELZreuQrO_voshm_Ml0cku8I0JO3m1PrxlwXc XasAcLN9PV7NVr.vjexlLwhNgwQukov0Hzhn94mmSo7JZCQoTB6l1.TPm7GZ 42S.u6daaQv1fVRqBcU9260Yb..2QxrYBqsGHl1d2x9nCM4tLE5B0h6ZNhe_ otbRHU33JREhOggtiyWTBcUaFZGhUPaNYnhN9YDFmVrCCbvZm35ueJjLvj6g 3qScQnVj05GKB0JFI4i3LnoDnXdlDGP9YG3rippEzuYIm Received: from [174.48.129.108] by web126005.mail.ne1.yahoo.com via HTTP; Fri, 27 Apr 2012 06:32:38 PDT X-Mailer: YahooMailClassic/15.0.6 YahooMailWebService/0.8.117.340979 Message-ID: <1335533558.95776.YahooMailClassic@web126005.mail.ne1.yahoo.com> Date: Fri, 27 Apr 2012 06:32:38 -0700 (PDT) From: Barney Cordoba To: Sami Halabi In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Intel 10 GbE cards (ixgbe) 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, 27 Apr 2012 13:32:44 -0000 How much traffic are you passing during peak times?=0A=0A--- On Wed, 4/25/1= 2, Sami Halabi wrote:=0A=0A> From: Sami Halabi =0A> Subject: Re: Intel 10 GbE cards (ixgbe)=0A> To: "Takuya A= SADA" =0A> Cc: freebsd-net@freebsd.org, "Marko Zec" =0A> Date: Wednesday, April 25, 2012, 10:13 AM=0A> Hi,=0A> I have i= t running on fbsd-8.1-r for more than 1.5 years now=0A> without issues,=0A>= i had problem when i first installed it, but they were=0A> disappeared whe= n i=0A> installed 2.3.8 driver, today there is 2.4 versionon=0A> stable.=0A= > =0A> Sami=0A> =0A> On Wed, Apr 25, 2012 at 2:25 PM, Takuya ASADA =0A> wrote:=0A> =0A> > Hi Marko,=0A> >=0A> > I had working on bp= f multiqueue support with 82599 in=0A> last year(on=0A> > -CURRENT), there'= s no issue for me.=0A> >=0A> > http://freebsd.1045724.n5.nabble.com/Multiqu= eue-support-for-bpf-td4703899.html=0A> >=0A> > Takuya ASADA=0A> >=0A> > 201= 2/4/25 Marko Zec :=0A> > > Hi all,=0A> > >=0A> > > Although the= ixgbe driver appears to have code for=0A> both 82598 and 82599=0A> > > chi= psets, the manual page stil lists only 82598=0A> based cards as officially= =0A> > > supported.=A0 Does anybody have first-hand=0A> experiences with 82= 599 based=0A> > cards=0A> > > and recent versions of the ixgbe driver (-CUR= RENT,=0A> 9.0, 8.3)?=0A> > >=0A> > > Thanks,=0A> > >=0A> > > Marko=0A> > > = _______________________________________________=0A> > > freebsd-net@freebsd= .org=0A> mailing list=0A> > > http://lists.freebsd.org/mailman/listinfo/fre= ebsd-net=0A> > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@= freebsd.org"=0A> > _______________________________________________=0A> > fr= eebsd-net@freebsd.org=0A> mailing list=0A> > http://lists.freebsd.org/mailm= an/listinfo/freebsd-net=0A> > To unsubscribe, send any mail to "freebsd-net= -unsubscribe@freebsd.org"=0A> >=0A> =0A> =0A> =0A> -- =0A> Sami Halabi=0A> = Information Systems Engineer=0A> NMS Projects Expert=0A> __________________= _____________________________=0A> freebsd-net@freebsd.org=0A> mailing list= =0A> http://lists.freebsd.org/mailman/listinfo/freebsd-net=0A> To unsubscri= be, send any mail to "freebsd-net-unsubscribe@freebsd.org"=0A> From owner-freebsd-net@FreeBSD.ORG Fri Apr 27 19:41:45 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 EE076106566B; Fri, 27 Apr 2012 19:41:45 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.freebsd.org (Postfix) with ESMTP id D147F8FC15; Fri, 27 Apr 2012 19:41:45 +0000 (UTC) Received: from [IPv6:::1] (proxy7.corp.yahoo.com [216.145.48.98]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q3RJTAdB060431; Fri, 27 Apr 2012 12:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1335554950; bh=CJm6q0dNCAH0muvvEqoyugl/eTW4Lx5xDFXElewUyig=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=JDzjjpeOgEX56oCrzt8a4Q2b4FUpdA4MHdgGNVl9+107xdLCGfb5Y0o4RStERoQM8 YIG5IArxUGQDSNDxNarcwx8TU5SHzIPBHfs0wXGj3uwXRlC4c5H8JKl02NXv+6iRzb QZUMtg8qIeqFBiPeeKR5uHUo3aofyhkJ45j6Ae/4= From: Sean Bruno To: Juli Mallett In-Reply-To: References: <1335463643.2727.10.camel@powernoodle-l7.corp.yahoo.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 27 Apr 2012 12:29:10 -0700 Message-ID: <1335554950.9324.3.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: igb(4) at peak in big purple 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, 27 Apr 2012 19:41:46 -0000 On Thu, 2012-04-26 at 11:13 -0700, Juli Mallett wrote: > Queue splitting in Intel cards is done using a hash of protocol > headers, so this is expected behavior. This also helps with TCP and > UDP performance, in terms of keeping packets for the same protocol > control block on the same core, but for other applications it's not > ideal. If your application does not require that kind of locality, > there are things that can be done in the driver to make it easier to > balance packets between all queues about-evenly. Oh? :-) What should I be looking at to balance more evenly? sean From owner-freebsd-net@FreeBSD.ORG Fri Apr 27 20:00:58 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 E4A781065674 for ; Fri, 27 Apr 2012 20:00:57 +0000 (UTC) (envelope-from juli@clockworksquid.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 6D18C8FC21 for ; Fri, 27 Apr 2012 20:00:57 +0000 (UTC) Received: by weyt57 with SMTP id t57so842680wey.13 for ; Fri, 27 Apr 2012 13:00:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=r5WLLgJQaqG3IOTvnIEqTxBEUZh4CNx3ysWgMg5rCo8=; b=du8vPB5d6y42dQIhyGnF9eE/lgilX+aXMMhu+a9R+dMUOEiKvxg6cmuV19HeRXl7Bf Bu+fL0NIpHxTm9CRsyk+c+K9MO2TDFMMaB2hWjLL6bARxrZStZ2UUhqCXaBRg+F0ciGe nXrZ4I4t6Q0RVjPT/M/K2Bjc1MWZACphI6vSlTx2Mpt7yQ3ymsHpewrJ8eqcr6pmoKmt 1OvKm6gUn08uUMjWlp80ERvWSFR0vP+VSAMXooRkQT0BPds8qxAYPpaWjV9BoFXR3ILI pjC4ngWru7UE+cvmcSJ0mklDBe2eoYzQVS7WD83S3ATHaANxXlzNk7/SQeBvmL923o5u Ic3w== Received: by 10.180.94.161 with SMTP id dd1mr8898465wib.16.1335556856266; Fri, 27 Apr 2012 13:00:56 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.216.110.67 with HTTP; Fri, 27 Apr 2012 13:00:36 -0700 (PDT) In-Reply-To: <1335554950.9324.3.camel@powernoodle-l7.corp.yahoo.com> References: <1335463643.2727.10.camel@powernoodle-l7.corp.yahoo.com> <1335554950.9324.3.camel@powernoodle-l7.corp.yahoo.com> From: Juli Mallett Date: Fri, 27 Apr 2012 13:00:36 -0700 X-Google-Sender-Auth: s0o9hV8toJVauQFd5Ol55uDF1eg Message-ID: To: Sean Bruno Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn6RuPZfzY3IlRlZ2FUjhpq+F9FCRVhiGYQujT7Hg4eSjaFNdpW+IFKvzI2wb4DIeg2fhBY Cc: "freebsd-net@freebsd.org" Subject: Re: igb(4) at peak in big purple 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, 27 Apr 2012 20:00:58 -0000 On Fri, Apr 27, 2012 at 12:29, Sean Bruno wrote: > On Thu, 2012-04-26 at 11:13 -0700, Juli Mallett wrote: >> Queue splitting in Intel cards is done using a hash of protocol >> headers, so this is expected behavior. =C2=A0This also helps with TCP an= d >> UDP performance, in terms of keeping packets for the same protocol >> control block on the same core, but for other applications it's not >> ideal. =C2=A0If your application does not require that kind of locality, >> there are things that can be done in the driver to make it easier to >> balance packets between all queues about-evenly. > > Oh? :-) > > What should I be looking at to balance more evenly? Dirty hacks are involved :) I've sent some code to Luigi that I think would make sense in netmap (since for many tasks one's going to do with netmap, you want to use as many cores as possible, and maybe don't care about locality so much) but it could be useful in conjunction with the network stack, too, for tasks that don't need a lot of locality. Basically this is the deal: the Intel NICs hash of various header fields. Then, some bits from that hash are used to index a table. That table indicates what queue the received packet should go to. Ideally you'd want to use some sort of counter to index that table and get round-robin queue usage if you wanted to evenly saturate all cores. Unfortunately there doesn't seem to be a way to do that. What you can do, though, is regularly update the table that is indexed by hash. Very frequently, in fact, it's a pretty fast operation. So what I've done, for example, is to go through an rotate all of the entries every N packets, where N is something like the number of receive descriptors per queue divided by the number of queues. So bucket 0 goes to queue 0 and bucket 1 goes to queue 1 at first. Then a few hundred packets are received, and the table is reprogrammed, so now bucket 0 goes to queue 1 and bucket 1 goes to queue 0. I can provide code to do this, but I don't want to post it publicly (unless it is actually going to become an option for netmap) for fear that people will use it in scenarios where it's harmful and then complain. It's potentially one more painful variation for the Intel drivers that Intel can't support, and that just makes everyone miserable. Thanks, Juli. From owner-freebsd-net@FreeBSD.ORG Fri Apr 27 20:06:59 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 89CE81065670; Fri, 27 Apr 2012 20:06:59 +0000 (UTC) (envelope-from jfvogel@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 D76018FC24; Fri, 27 Apr 2012 20:06:58 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so1003476wgb.31 for ; Fri, 27 Apr 2012 13:06:57 -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=CIzFO3kh69vqKIddIhAcUxS0doA0GM481nQnD2a/aR0=; b=SvtVUNyw7d/m7d8iH/nsRbYqFdkdD6tMrIrIAVccmvKdyuva2LQWEvzK6/94uFAdX/ clTs/AfVZMXUdcuX9V8TuWjsd18GZ6xAgMh6dkDIXaTjgMZOuET5yPZzSJC8BYv6jG0h Z02Ge3FpOpAXVvEuvscATQinRj858lDZSeaqLKFKbCDqbn7kTqPbObH5eDXepk8b0pKn cMpQAukl2cmUUjQObqb0B0GG80/Zc/32J3UQfoRRfIw0W6J/hYFTy9tgGFAOJYnoR0B9 uiVJ73119ukv1WcPMtnAZAC9Ws5zhNjiDzqGUr6V/WIm6wGLpJCVuyoMHUxGXldTRb3I Y1Wg== MIME-Version: 1.0 Received: by 10.216.137.22 with SMTP id x22mr8829407wei.69.1335557217793; Fri, 27 Apr 2012 13:06:57 -0700 (PDT) Received: by 10.180.145.162 with HTTP; Fri, 27 Apr 2012 13:06:57 -0700 (PDT) In-Reply-To: References: <1335463643.2727.10.camel@powernoodle-l7.corp.yahoo.com> <1335554950.9324.3.camel@powernoodle-l7.corp.yahoo.com> Date: Fri, 27 Apr 2012 13:06:57 -0700 Message-ID: From: Jack Vogel To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" , Sean Bruno Subject: Re: igb(4) at peak in big purple 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, 27 Apr 2012 20:06:59 -0000 I suspect to do it right would involve having the stack/kernel have more interaction with the driver/interface data, and this IS the way RSS was envisioned to work. Its been talked about but hasn't happened so far. Jack On Fri, Apr 27, 2012 at 1:00 PM, Juli Mallett wrote: > On Fri, Apr 27, 2012 at 12:29, Sean Bruno wrote: > > On Thu, 2012-04-26 at 11:13 -0700, Juli Mallett wrote: > >> Queue splitting in Intel cards is done using a hash of protocol > >> headers, so this is expected behavior. This also helps with TCP and > >> UDP performance, in terms of keeping packets for the same protocol > >> control block on the same core, but for other applications it's not > >> ideal. If your application does not require that kind of locality, > >> there are things that can be done in the driver to make it easier to > >> balance packets between all queues about-evenly. > > > > Oh? :-) > > > > What should I be looking at to balance more evenly? > > Dirty hacks are involved :) I've sent some code to Luigi that I think > would make sense in netmap (since for many tasks one's going to do > with netmap, you want to use as many cores as possible, and maybe > don't care about locality so much) but it could be useful in > conjunction with the network stack, too, for tasks that don't need a > lot of locality. > > Basically this is the deal: the Intel NICs hash of various header > fields. Then, some bits from that hash are used to index a table. > That table indicates what queue the received packet should go to. > Ideally you'd want to use some sort of counter to index that table and > get round-robin queue usage if you wanted to evenly saturate all > cores. Unfortunately there doesn't seem to be a way to do that. > > What you can do, though, is regularly update the table that is indexed > by hash. Very frequently, in fact, it's a pretty fast operation. So > what I've done, for example, is to go through an rotate all of the > entries every N packets, where N is something like the number of > receive descriptors per queue divided by the number of queues. So > bucket 0 goes to queue 0 and bucket 1 goes to queue 1 at first. Then > a few hundred packets are received, and the table is reprogrammed, so > now bucket 0 goes to queue 1 and bucket 1 goes to queue 0. > > I can provide code to do this, but I don't want to post it publicly > (unless it is actually going to become an option for netmap) for fear > that people will use it in scenarios where it's harmful and then > complain. It's potentially one more painful variation for the Intel > drivers that Intel can't support, and that just makes everyone > miserable. > > Thanks, > Juli. > _______________________________________________ > 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 Fri Apr 27 20:42: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 057E6106564A; Fri, 27 Apr 2012 20:42:40 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id B6F328FC17; Fri, 27 Apr 2012 20:42:39 +0000 (UTC) Received: by dadz14 with SMTP id z14so4920665dad.17 for ; Fri, 27 Apr 2012 13:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KFarAbheAZ1CUzw2EUou2csUYk9naN4tWQDaENAQdYo=; b=yoqS1YKOSGja7SNFrdus8vv9IWFrLen7DdBdLeosQGCOQjBDbBcZPwJ9AsuSEnhNat strdR6+niz1RnNtWtwoRzil/ABhzLPwB1mNKrszRwrgVO84UksWfpbEDY5ajZBPM3Qqz WdFTcim+BbqBcE1BsbD5lBm8BCv3Jo5tSDPGgqVWlj2dU807sZ6AHaNjjHf0Ywnn+Yz2 PXXW635UTeKiweZVBTP6nkred8fviRFgO5By8221g8KOZYD6GSLkA+z9ssMcH4G5aAjo JhA7OxRQJ/3zAUugueP+b6OqxSL/T+7q7A5H5HWNmCgVP4Q7t17cvjtDcuaueeca+6AA io8g== MIME-Version: 1.0 Received: by 10.68.213.200 with SMTP id nu8mr13956780pbc.59.1335559359538; Fri, 27 Apr 2012 13:42:39 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.142.101.9 with HTTP; Fri, 27 Apr 2012 13:42:39 -0700 (PDT) In-Reply-To: <4F91240C.3050703@ipfw.ru> References: <201204060653.q366rwLa096182@svn.freebsd.org> <4F7E9413.20602@FreeBSD.org> <4F8BBD4E.1040106@FreeBSD.org> <4F91240C.3050703@ipfw.ru> Date: Fri, 27 Apr 2012 13:42:39 -0700 X-Google-Sender-Auth: wFTBDahJZWfGg4fbgug1a9YSzhQ Message-ID: From: Adrian Chadd To: "Alexander V. Chernikov" Content-Type: text/plain; charset=ISO-8859-1 Cc: svn-src-head@freebsd.org, freebsd-net@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r233937 - in head/sys: kern net security/mac 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, 27 Apr 2012 20:42:40 -0000 Hi Alex, I don't want to be demanding, but would you please consider committing your fixes? And if you could, would you please do it as a set of commits, one per 'thing', rather than one big monolithic commit that does half a dozen different things? That way if there are any further regressions, I/others could test things out. This is breaking bpf for a few people - ladv causes a crash, wifi also causes a crash. Thanks! Adrian From owner-freebsd-net@FreeBSD.ORG Fri Apr 27 21:48:53 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 CE8EF106564A for ; Fri, 27 Apr 2012 21:48:53 +0000 (UTC) (envelope-from mattmiller1@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8810A8FC08 for ; Fri, 27 Apr 2012 21:48:53 +0000 (UTC) Received: by vcmm1 with SMTP id m1so1167584vcm.13 for ; Fri, 27 Apr 2012 14:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=1pJO2ZNOzPwxcI1dEF2DKLScbD/03FpWF7Ef2iuQ7xA=; b=TGW8y+/OIZCFqnC6K93Qi1iNHyRbKEJivPjuTZvkPzvnywHEBgdip94WMz7HvufKt7 f6LhbFHHE9eB6CjgcGXp9jCz56gAuNb5zxVTPmIfW0EqNWiaw7DOLfsoa/dfv1pRqof5 1sRhccYydr4RCOQYZovbjZQIzmbV9vB6yXEm2/Tu6VltnLzOPvwdM9jjQa46WO2RzNjI 4sL1vZe5eXGNKI1b/ITzpDQ/ZjZW28e/mwSQOCFeHNUxRikNOIkVMOaqr5u05Hg/eTv/ cVklC0i926pCIC+u/JVc1CFwJ/ruBoHJycS59r/5ch+Pv5tZAQNS1itipA6Oce71Njz8 Kamw== Received: by 10.220.63.9 with SMTP id z9mr12749788vch.64.1335563326901; Fri, 27 Apr 2012 14:48:46 -0700 (PDT) MIME-Version: 1.0 Sender: mattmiller1@gmail.com Received: by 10.220.178.12 with HTTP; Fri, 27 Apr 2012 14:48:06 -0700 (PDT) From: Matt Miller Date: Fri, 27 Apr 2012 17:48:06 -0400 X-Google-Sender-Auth: Aqw6-odwrFfJN2Yuf2ZxJD7hbiE Message-ID: To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Alloc Error Handling in lib/libc/rpc/svc.c 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, 27 Apr 2012 21:48:53 -0000 In an OOM condition, we noticed a couple of mem_alloc handling bugs in this file. Please let me know if a PR should be opened for these. - No NULL checks after mem_alloc()'s: SVCXPRT * svc_xprt_alloc() { SVCXPRT *xprt; SVCXPRT_EXT *ext; xprt = mem_alloc(sizeof(SVCXPRT)); memset(xprt, 0, sizeof(SVCXPRT)); ext = mem_alloc(sizeof(SVCXPRT_EXT)); memset(ext, 0, sizeof(SVCXPRT_EXT)); xprt->xp_p3 = ext; ext->xp_auth.svc_ah_ops = &svc_auth_null_ops; return (xprt); } - No lock release if mem_alloc() returns NULL: void xprt_register(xprt) SVCXPRT *xprt; { int sock; assert(xprt != NULL); sock = xprt->xp_fd; rwlock_wrlock(&svc_fd_lock); if (__svc_xports == NULL) { __svc_xports = (SVCXPRT **) mem_alloc(FD_SETSIZE * sizeof(SVCXPRT *)); if (__svc_xports == NULL) return; memset(__svc_xports, '\0', FD_SETSIZE * sizeof(SVCXPRT *)); } if (sock < FD_SETSIZE) { __svc_xports[sock] = xprt; FD_SET(sock, &svc_fdset); svc_maxfd = max(svc_maxfd, sock); } rwlock_unlock(&svc_fd_lock); } Thanks, Matt From owner-freebsd-net@FreeBSD.ORG Fri Apr 27 23:11:54 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 F2238106566B; Fri, 27 Apr 2012 23:11:54 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by mx1.freebsd.org (Postfix) with ESMTP id BE8A48FC08; Fri, 27 Apr 2012 23:11:54 +0000 (UTC) Received: from [10.9.208.27] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Fri, 27 Apr 2012 16:08:50 -0700 X-Server-Uuid: 72204117-5C29-4314-8910-60DB108979CB Received: from IRVEXCHCAS07.corp.ad.broadcom.com (10.9.208.55) by irvexchmb05.corp.ad.broadcom.com (10.9.208.27) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 27 Apr 2012 16:08:39 -0700 Received: from IRVEXCHMB11.corp.ad.broadcom.com ( [fe80::9cdd:3a57:8694:f610]) by IRVEXCHCAS07.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Fri, 27 Apr 2012 16:08:39 -0700 From: "David Christensen" To: "pyunyh@gmail.com" , "Andrey Zonov" Thread-Topic: bce: jumbo not working since r218423 Thread-Index: AQHNI58ETiBicQtXXEaswP/sqsS0Y5avwioA//+KO9A= Date: Fri, 27 Apr 2012 23:08:38 +0000 Message-ID: <3A5015FE9E557D448AF7238AF0ACE20A129751@IRVEXCHMB11.corp.ad.broadcom.com> References: <20120427230400.GB17009@michelle.cdnetworks.com> In-Reply-To: <20120427230400.GB17009@michelle.cdnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.145.68] MIME-Version: 1.0 X-WSS-ID: 6385F8883JG1867102-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , "davidch@freebsd.org" Subject: RE: bce: jumbo not working since r218423 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, 27 Apr 2012 23:11:55 -0000 >> I also don't understand why sysctl hw.bce.loose_rx_mtu doesn't respect >> with tunnable hw.bce.strict_rx_mtu. Is there any reason to give them >> different names? >It may be an oversight. Personally I don't see any reason except >debugging purpose to limit RX frame size to interface MTU. It makes >sense when controller send frames but it should be able to receive >any sized RX frames(if controller allows it). Dropping RX frames >that are bigger than interface MTU would break path MTU discovery >of remote host that uses bigger MTU. The intent was to pass compliance tests such as those performed at UNH by limiting the MTU to the size allowed by the IEEE 802.3 specification. (No one likes explaining such failures to customers.) As you indicate, rea= l=20 world applications benefit from loose compliance on RX so a single tunable is all that's intended to enable/disable the behavior. Dave From owner-freebsd-net@FreeBSD.ORG Fri Apr 27 23:37: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 04221106564A; Fri, 27 Apr 2012 23:37:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id BFD5B8FC12; Fri, 27 Apr 2012 23:37:41 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so132045pbb.13 for ; Fri, 27 Apr 2012 16:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8YUfmw0+ULtX/BcjCELQdzzN+r2TFEBAWLQ/2Rdu7Cw=; b=aDMQK8R5wGw2bTrRasG/YkZlZBekk3sW8viBxkoZzsPTFp9IeCAFHpV9o+9ggrzBCE cBziL22pHsMEZI0ha0nIRTsmokxe1FscvFKYGW5bzos5gaNIstn05gQOZvinlgzNRmR7 yh1raM3J15Ywulm8tF0D9qpCI7fXsG+CAENzoeBMrsiGfpoB4WTjPh+mCEeQXiYNvXFh j5EB90TJU9Uj5peEoOqptB7YdX7QwRI2P/Ez0wg+d5UZ/+DkGKiehsPlfBnk/WX186z5 qEABZyw1gyct4XmGowg0E7EBR8Zw39U/kRChhCJeTbj7OT8bCO47i+7YI1gZ78xRlxzL G6Yw== MIME-Version: 1.0 Received: by 10.68.236.165 with SMTP id uv5mr7348072pbc.37.1335569861180; Fri, 27 Apr 2012 16:37:41 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.142.101.9 with HTTP; Fri, 27 Apr 2012 16:37:41 -0700 (PDT) In-Reply-To: <3A5015FE9E557D448AF7238AF0ACE20A129751@IRVEXCHMB11.corp.ad.broadcom.com> References: <20120427230400.GB17009@michelle.cdnetworks.com> <3A5015FE9E557D448AF7238AF0ACE20A129751@IRVEXCHMB11.corp.ad.broadcom.com> Date: Fri, 27 Apr 2012 16:37:41 -0700 X-Google-Sender-Auth: dfphqtQXxNhYiB7Z-q49vzcSeX0 Message-ID: From: Adrian Chadd To: David Christensen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pyunyh@gmail.com" , "freebsd-net@freebsd.org" , Andrey Zonov , "davidch@freebsd.org" Subject: Re: bce: jumbo not working since r218423 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, 27 Apr 2012 23:37:42 -0000 On 27 April 2012 16:08, David Christensen wrote: > The intent was to pass compliance tests such as those performed at UNH > by limiting the MTU to the size allowed by the IEEE 802.3 specification. > (No one likes explaining such failures to customers.) =A0As you indicate,= real > world applications benefit from loose compliance on RX so a single > tunable is all that's intended to enable/disable the behavior. May I suggest (if it isn't already) documenting this in the driver manpage? that way it's not forgotten by some future hacker and removed for being "useless" ? :-) Thanks! Adrian From owner-freebsd-net@FreeBSD.ORG Sat Apr 28 09:23:32 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 DE85D1065674; Sat, 28 Apr 2012 09:23:32 +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 2E25A8FC17; Sat, 28 Apr 2012 09:23:31 +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 q3S9NTRq077884; Sat, 28 Apr 2012 16:23:29 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4F9BB711.5090604@rdtc.ru> Date: Sat, 28 Apr 2012 16:23:29 +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: "net@freebsd.org" , Jack F Vogel Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: 82576EB IPSec offload and igb(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: Sat, 28 Apr 2012 09:23:32 -0000 Hi! What is current status of IPSec offload support for Intel 82576EB Gigabit Ethernet controller in igb(4) driver? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sat Apr 28 10:16:14 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 1F8E9106566B for ; Sat, 28 Apr 2012 10:16:14 +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 949B78FC0A for ; Sat, 28 Apr 2012 10:16:13 +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 q3SAG3NT033247; Sat, 28 Apr 2012 13:16:03 +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 q3SAG3k4092218; Sat, 28 Apr 2012 13:16:03 +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 q3SAG1C5092217; Sat, 28 Apr 2012 13:16:01 +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: Sat, 28 Apr 2012 13:16:01 +0300 From: Konstantin Belousov To: Matt Miller Message-ID: <20120428101601.GG2358@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="I5DvuL84SVjYoYOv" Content-Disposition: inline In-Reply-To: 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: net@freebsd.org Subject: Re: Alloc Error Handling in lib/libc/rpc/svc.c 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, 28 Apr 2012 10:16:14 -0000 --I5DvuL84SVjYoYOv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 27, 2012 at 05:48:06PM -0400, Matt Miller wrote: > In an OOM condition, we noticed a couple of mem_alloc handling bugs in > this file. Please let me know if a PR should be opened for these. >=20 > - No NULL checks after mem_alloc()'s: >=20 > SVCXPRT * > svc_xprt_alloc() > { > SVCXPRT *xprt; > SVCXPRT_EXT *ext; >=20 > xprt =3D mem_alloc(sizeof(SVCXPRT)); > memset(xprt, 0, sizeof(SVCXPRT)); > ext =3D mem_alloc(sizeof(SVCXPRT_EXT)); > memset(ext, 0, sizeof(SVCXPRT_EXT)); > xprt->xp_p3 =3D ext; > ext->xp_auth.svc_ah_ops =3D &svc_auth_null_ops; >=20 > return (xprt); > } >=20 > - No lock release if mem_alloc() returns NULL: >=20 > void > xprt_register(xprt) > SVCXPRT *xprt; > { > int sock; >=20 > assert(xprt !=3D NULL); >=20 > sock =3D xprt->xp_fd; >=20 > rwlock_wrlock(&svc_fd_lock); > if (__svc_xports =3D=3D NULL) { > __svc_xports =3D (SVCXPRT **) > mem_alloc(FD_SETSIZE * sizeof(SVCXPRT *)); > if (__svc_xports =3D=3D NULL) > return; > memset(__svc_xports, '\0', FD_SETSIZE * sizeof(SVCXPRT *)); > } > if (sock < FD_SETSIZE) { > __svc_xports[sock] =3D xprt; > FD_SET(sock, &svc_fdset); > svc_maxfd =3D max(svc_maxfd, sock); > } > rwlock_unlock(&svc_fd_lock); > } Thank you for the report. Does the patch below look fine to you ? diff --git a/lib/libc/rpc/svc.c b/lib/libc/rpc/svc.c index 282c2be..78a8ae1 100644 --- a/lib/libc/rpc/svc.c +++ b/lib/libc/rpc/svc.c @@ -108,8 +108,10 @@ xprt_register(xprt) if (__svc_xports =3D=3D NULL) { __svc_xports =3D (SVCXPRT **) mem_alloc(FD_SETSIZE * sizeof(SVCXPRT *)); - if (__svc_xports =3D=3D NULL) + if (__svc_xports =3D=3D NULL) { + rwlock_unlock(&svc_fd_lock); return; + } memset(__svc_xports, '\0', FD_SETSIZE * sizeof(SVCXPRT *)); } if (sock < FD_SETSIZE) { @@ -565,8 +567,14 @@ svc_xprt_alloc() SVCXPRT_EXT *ext; =20 xprt =3D mem_alloc(sizeof(SVCXPRT)); + if (xprt =3D=3D NULL) + return (NULL); memset(xprt, 0, sizeof(SVCXPRT)); ext =3D mem_alloc(sizeof(SVCXPRT_EXT)); + if (ext =3D=3D NULL) { + mem_free(xprt, sizeof(SVCXPRT)); + return (NULL); + } memset(ext, 0, sizeof(SVCXPRT_EXT)); xprt->xp_p3 =3D ext; ext->xp_auth.svc_ah_ops =3D &svc_auth_null_ops; diff --git a/lib/libc/rpc/svc_raw.c b/lib/libc/rpc/svc_raw.c index 67bcba1..de95152 100644 --- a/lib/libc/rpc/svc_raw.c +++ b/lib/libc/rpc/svc_raw.c @@ -96,10 +96,22 @@ svc_raw_create() mutex_unlock(&svcraw_lock); return (NULL); } - if (__rpc_rawcombuf =3D=3D NULL) + if (__rpc_rawcombuf =3D=3D NULL) { __rpc_rawcombuf =3D calloc(UDPMSGSIZE, sizeof (char)); + if (__rpc_rawcombuf =3D=3D NULL) { + free(srp); + mutex_unlock(&svcraw_lock); + return (NULL); + } + } srp->raw_buf =3D __rpc_rawcombuf; /* Share it with the client */ srp->server =3D svc_xprt_alloc(); + if (srp->server =3D=3D NULL) { + free(__rpc_rawcombuf); + free(srp); + mutex_unlock(&svcraw_lock); + return (NULL); + } svc_raw_private =3D srp; } srp->server->xp_fd =3D FD_SETSIZE; --I5DvuL84SVjYoYOv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+bw2EACgkQC3+MBN1Mb4gOcwCfS1NhTjDDL85COhQhWbYU4Cj9 4YoAniCN5ua921mGMaxnUjualTTlXKFq =7ObQ -----END PGP SIGNATURE----- --I5DvuL84SVjYoYOv-- From owner-freebsd-net@FreeBSD.ORG Sat Apr 28 20:48:35 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 EA2A01065672 for ; Sat, 28 Apr 2012 20:48:35 +0000 (UTC) (envelope-from sodynet1@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 AC4DE8FC0C for ; Sat, 28 Apr 2012 20:48:35 +0000 (UTC) Received: by obcni5 with SMTP id ni5so3218616obc.13 for ; Sat, 28 Apr 2012 13:48:35 -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=pZrQvSYXdxlBnMyB2fOXWa9muWPHhJ+sF2tgFm6DpoE=; b=umkaIt0zXofbXC5IVQwCk2u5NJaH1QN1RMCPf7jpqHcOiyeeZhMSz0UD8Ojk2hp2g7 mlVUR4D6WaAcamTE0WP3dntHoR0uQQeuTKptwCiBbTlWbJN+czxWA0F2tayNJf0Wfopy KrDhDSI0CYAOKVe+AARRQLweS2HZLrnYbCp//qwcY/ubn0CPtookUzoEpdjH0cPmpVIB kR3r5ud1cLxUAvflBBeX+H9BYbOroXr7XyX2N7qAlClxXsVqqA93DKRmwNS4IKniO+U0 7kYM5UiAqHZiHxayoisxpPuopmZCFmm/FvkXupTt97ztAxCD6AmhOhbavjKbj2YFaSu8 3ieA== MIME-Version: 1.0 Received: by 10.60.9.102 with SMTP id y6mr21180627oea.46.1335646115121; Sat, 28 Apr 2012 13:48:35 -0700 (PDT) Received: by 10.182.166.100 with HTTP; Sat, 28 Apr 2012 13:48:34 -0700 (PDT) In-Reply-To: <1335533558.95776.YahooMailClassic@web126005.mail.ne1.yahoo.com> References: <1335533558.95776.YahooMailClassic@web126005.mail.ne1.yahoo.com> Date: Sat, 28 Apr 2012 23:48:34 +0300 Message-ID: From: Sami Halabi To: Barney Cordoba Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Intel 10 GbE cards (ixgbe) 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, 28 Apr 2012 20:48:36 -0000 for now 6G in production On Fri, Apr 27, 2012 at 4:32 PM, Barney Cordoba wrote: > How much traffic are you passing during peak times? > > --- On Wed, 4/25/12, Sami Halabi wrote: > > > From: Sami Halabi > > Subject: Re: Intel 10 GbE cards (ixgbe) > > To: "Takuya ASADA" > > Cc: freebsd-net@freebsd.org, "Marko Zec" > > Date: Wednesday, April 25, 2012, 10:13 AM > > Hi, > > I have it running on fbsd-8.1-r for more than 1.5 years now > > without issues, > > i had problem when i first installed it, but they were > > disappeared when i > > installed 2.3.8 driver, today there is 2.4 versionon > > stable. > > > > Sami > > > > On Wed, Apr 25, 2012 at 2:25 PM, Takuya ASADA > > wrote: > > > > > Hi Marko, > > > > > > I had working on bpf multiqueue support with 82599 in > > last year(on > > > -CURRENT), there's no issue for me. > > > > > > > http://freebsd.1045724.n5.nabble.com/Multiqueue-support-for-bpf-td4703899.html > > > > > > Takuya ASADA > > > > > > 2012/4/25 Marko Zec : > > > > Hi all, > > > > > > > > Although the ixgbe driver appears to have code for > > both 82598 and 82599 > > > > chipsets, the manual page stil lists only 82598 > > based cards as officially > > > > supported. Does anybody have first-hand > > experiences with 82599 based > > > cards > > > > and recent versions of the ixgbe driver (-CURRENT, > > 9.0, 8.3)? > > > > > > > > Thanks, > > > > > > > > Marko > > > > _______________________________________________ > > > > 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" > > > > > > > > > > > -- > > Sami Halabi > > Information Systems Engineer > > NMS Projects Expert > > _______________________________________________ > > 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" > > > -- Sami Halabi Information Systems Engineer NMS Projects Expert