From owner-freebsd-net@FreeBSD.ORG Tue Jan 1 00:43:26 2008 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 2A22B16A468 for ; Tue, 1 Jan 2008 00:43:26 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.freebsd.org (Postfix) with ESMTP id BEDFB13C455 for ; Tue, 1 Jan 2008 00:43:25 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m010hIF9014397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jan 2008 11:43:20 +1100 Date: Tue, 1 Jan 2008 11:43:18 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Julian Elischer In-Reply-To: <4779697A.4050806@elischer.org> Message-ID: <20080101105918.I9594@delplex.bde.org> References: <4779697A.4050806@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Net Subject: Re: m_freem() 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, 01 Jan 2008 00:43:26 -0000 On Mon, 31 Dec 2007, Julian Elischer wrote: > m_freem() would be a perfect candidate for an inline function. > (or even macro). > in the case where m is null, no function call would even be made... > The whole function is only 2 lines, and it gets called once for every packet > :-) On the contrary, m_freem() is a large function that is fairly unsuitable for inlining. I just happened to count that it usually takes 180 instructions in -current with no INVARIANTS etc. (down from 245 instructions in ~5.2). Further counting gave 112 and 132 instructions for it (180 was for ttcp udp input packets and 112 and 132 are for ping packets in 2 directions). m_freem() is only one statement, but that statement consists mainly of a function call to a function that is inline (m_free()). m_free() sometimes calls m_free_ext(), which is not inline, and usually calls uma_zfree(), which is inline, but which is just a wrapper for uma_zfree_arg(), which is not inline. uma_zfree_arg() is very large and thus very unsuitable for inlining. I didn't check for [nested] inlining of its internals at the source level. At runtime it usually calls the non-inline-function m_dtor_mbuf() which calls the non-inline function m_tag_delete_chain(); then it calls critical_enter() and critical_exit(). critical_exit() is fairly large and sometimes calls thread_lock(), mi_switch() and thread_unlock(), but usually doesn't. So the non-inline part of the call chain is usually: m_freem() uma_zfree_arg() # the following is just 1 short path through this m_dtor_mbuf() m_tag_delete_chain() critical_enter() critical_exit() [Pause to recover from a double fault panic in critical*(). critical*() or kdb is non-reeantrant somehwere, so tracing through critical_*() or one of its callers in order to count instructions tends to cause panics.] All this is too large to inline. Inlining only the top level of it would only make a tiny difference. It might make a positive or negative difference, depending on whether the reduced instruction count has a larger effect than the increased cache pressure. Generally I think it is bogus to inline at the top level. Here inlining at the top level may win in 2 ways: - by avoiding the function call to the next level (and thus all function calls) in the usual case. I think this doesn't happen here. I think it is the usual case for the m_free_ext() call in m_free(), so inlining m_free() is a clear win. - by improving branch prediction. With a branch in a non-inline function, it may be mispredicted often because different classes of callers make it go in different ways. With branch the distributed in callers by inlining, it can be predicted perfectly in individual callers that don't change its direction often and/or change its direction in predictable ways. On Athlon CPUs, mispredicting a single branch costs the same several function calls provided the implicit branches for all the function calls are not mispredicted. Too much inlining is still bad. Apart from busting icaches, it can bust branch prediction caches -- with enough distribution of branches, all branches will be mispredicted. The m_freem() wrapper currently limits the icache bloat from the m_free() inline. In RELENG_4, both m_free() and m_freem() are non-inline and non-macro. That may be why networking in RELENG_4 is so much more efficient than in -current ;-). (Actually it makes little difference.) Bruce From owner-freebsd-net@FreeBSD.ORG Tue Jan 1 06:55:02 2008 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 D0E0B16A481 for ; Tue, 1 Jan 2008 06:55:02 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id A4F2C13C457 for ; Tue, 1 Jan 2008 06:55:02 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so8580309waf.3 for ; Mon, 31 Dec 2007 22:55:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=UNDDGaNq+qK9j2H8tmJiDi2IH7+/nQ46F9cT4C9ccb4=; b=Jk0Ws1z+FtlBt29ovSqzpG4DMq75weAjSQganWgjBsAdl48QfqXZCeoNVj4g5jFySuSGrOIsslOX+USqb+3esYVRkcDwa7A9wXYI+sqW4fq0j8Bkikcltdno7OgUDVKKXGZI3N8l24f4aDizfWhJNrWvx6o4LlNvH4qbOV8qddA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rK/Xd2po2K91edq41HVBy5/fD+mT/cHtFD7wB/kWPcbGTITOtyXbkR4IgR/NEK9NWcX6TIi/bFAS35ZjJkA4vThBmmBOxnNkq1okSjoav8t/R/XtYWZIn1/f/pVblK2RIdakRmVLB2iea6chwuby8+MCrnz9X2XtCs/4fuC4Mj4= Received: by 10.142.215.5 with SMTP id n5mr3713133wfg.161.1199168867374; Mon, 31 Dec 2007 22:27:47 -0800 (PST) Received: by 10.142.162.20 with HTTP; Mon, 31 Dec 2007 22:27:47 -0800 (PST) Message-ID: Date: Tue, 1 Jan 2008 14:27:47 +0800 From: "Sepherosa Ziehau" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86ir2hznnd.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <86ir2hznnd.fsf@ds4.des.no> Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2008 06:55:03 -0000 On Dec 29, 2007 8:33 PM, Dag-Erling Sm=F8rgrav wrote: > I upgraded my router cum firewall cum access point (soekris net4801 with > a cheap third-party ralink-based wlan adapter) from RELENG_6 to HEAD and > noticed what seems to be a regression in if_ral. After a certain amount > of use (i.e. actually having a client connected to it and transferring > data), the connection falters, and eventually the client can no longer > see even see the access point in a scan. Restarting the interface on > the router (/etc/rc.d/netif restart ral0) fixes it. I now have a cron > job that does this every five minutes. I still get occasional outages, > but all I have to do is wait a few minutes for the cron job to kick in. > > Outages are clearly related to traffic; a sure-fire way to trigger one > is to start a backup job on my laptop (rsync to my file server). I will > lose the wlan connection repeatedly until I either stop trying or run > the script with a bandwidth limit. > > des@soe ~% uname -a > FreeBSD soe.des.no 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Dec 15 20:46:2= 9 UTC 2007 des@pwd.des.no:/usr/obj/usr/src/sys/soe i386 > des@soe ~% kldstat -v > Id Refs Address Size Name > 1 18 0xc0400000 33fdfc kernel (/boot/soe/kernel) > 2 1 0xc0740000 7690 if_sis.ko (/boot/soe/if_sis.ko) > 3 2 0xc0748000 1dbe0 miibus.ko (/boot/soe/miibus.ko) > 4 1 0xc0766000 18e28 if_ral.ko (/boot/soe/if_ral.ko) > 5 4 0xc077f000 2a95c wlan.ko (/boot/soe/wlan.ko) > 6 1 0xc07aa000 2cb0 wlan_acl.ko (/boot/soe/wlan_acl.ko) > 7 1 0xc07ad000 1924 wlan_scan_ap.ko (/boot/soe/wlan_scan_ap.ko) > 8 1 0xc107f000 6000 geom_md.ko (/boot/soe/geom_md.ko) > 9 1 0xc10f9000 2000 pflog.ko (/boot/soe/pflog.ko) > 10 1 0xc10fb000 2f000 pf.ko (/boot/soe/pf.ko) > 11 4 0xc118d000 a000 netgraph.ko (/boot/soe/netgraph.ko) > 12 1 0xc119c000 3000 ng_ether.ko (/boot/soe/ng_ether.ko) > 13 1 0xc11a8000 5000 ng_pppoe.ko (/boot/soe/ng_pppoe.ko) > 14 1 0xc11ad000 4000 ng_socket.ko (/boot/soe/ng_socket.ko) > des@soe ~% grep ral0 /var/run/dmesg.boot > ral0: mem 0xa0004000-0xa0005fff irq 11 at devi= ce 10.0 on pci0 I don't whether following thingies will fix your problem: 1) rt2560.c: rt2560_setup_tx_desc() Set RT2560_{TX,TX_CIPHER}_BUSY desc flag at the end of this function, instead of at the beginning of this function. The original way _may_ confuse hardware encryption/tx engine. 2) And the rt2560_bbp_read() is not correct, it should look like following: static uint8_t rt2560_bbp_read(struct rt2560_softc *sc, uint8_t reg) { =09uint32_t val; =09int ntries; =09for (ntries =3D 0; ntries < 100; ntries++) { =09=09if (!(RAL_READ(sc, RT2560_BBPCSR) & RT2560_BBP_BUSY)) =09=09=09break; =09=09DELAY(1); =09} =09if (ntries =3D=3D 100) { =09=09device_printf(sc->sc_dev, "could not read from BBP\n"); =09=09return 0; =09} =09val =3D RT2560_BBP_BUSY | reg << 8; =09RAL_WRITE(sc, RT2560_BBPCSR, val); =09for (ntries =3D 0; ntries < 100; ntries++) { =09=09val =3D RAL_READ(sc, RT2560_BBPCSR); =09=09if (!(val & RT2560_BBP_BUSY)) =09=09=09return val & 0xff; =09=09DELAY(1); =09} =09device_printf(sc->sc_dev, "could not read from BBP\n"); =09return 0; } 3) After above fix, rt2560_set_txantenna() and rt2560_set_rxantenna() should be called after rt2560_bbp_init(), since above two function touch BBP. NOTE: without above fix, you may burn your card. Even with these in place in dfly, I still have strange TX performance regression in sta mode (drop from 20Mb/s to 3Mb/s under very well condition) on certain hardwares after 20sec~30sec TCP_STREAM netperf testing; didn't have enough time to dig, however, all of the tested hardwares stayed connected during testing (I usually run netperf stream test for 12 hours or more). Best Regards, sephe --=20 Live Free or Die From owner-freebsd-net@FreeBSD.ORG Tue Jan 1 11:50:41 2008 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 1A7E616A417; Tue, 1 Jan 2008 11:50:41 +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 E844C13C44B; Tue, 1 Jan 2008 11:50:40 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m01Boe5H044511; Tue, 1 Jan 2008 11:50:40 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m01BoeoE044507; Tue, 1 Jan 2008 11:50:40 GMT (envelope-from remko) Date: Tue, 1 Jan 2008 11:50:40 GMT Message-Id: <200801011150.m01BoeoE044507@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/119225: 7.0-RC1 no carrier with Prism 2.5 wifi card 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, 01 Jan 2008 11:50:41 -0000 Synopsis: 7.0-RC1 no carrier with Prism 2.5 wifi card Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Tue Jan 1 11:50:27 UTC 2008 Responsible-Changed-Why: reassign to networking team http://www.freebsd.org/cgi/query-pr.cgi?pr=119225 From owner-freebsd-net@FreeBSD.ORG Tue Jan 1 13:32:26 2008 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 4AA7B16A46B; Tue, 1 Jan 2008 13:32:26 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 040BD13C4E3; Tue, 1 Jan 2008 13:32:25 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id C76A420A0; Tue, 1 Jan 2008 14:32:16 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.1/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id B95E9209C; Tue, 1 Jan 2008 14:32:16 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 983FC8449F; Tue, 1 Jan 2008 14:32:16 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Sepherosa Ziehau" References: <86ir2hznnd.fsf@ds4.des.no> Date: Tue, 01 Jan 2008 14:32:16 +0100 In-Reply-To: (Sepherosa Ziehau's message of "Tue\, 1 Jan 2008 14\:27\:47 +0800") Message-ID: <86abnpu0wv.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2008 13:32:26 -0000 "Sepherosa Ziehau" writes: > I don't whether following thingies will fix your problem: > [...] Can you provide a diff? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-net@FreeBSD.ORG Tue Jan 1 18:56:39 2008 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 5536D16A420 for ; Tue, 1 Jan 2008 18:56:39 +0000 (UTC) (envelope-from root@lupin.parts-unknown.org) Received: from lupin.parts-unknown.org (lupin.cybernude.org [66.93.170.242]) by mx1.freebsd.org (Postfix) with SMTP id E33E113C4EA for ; Tue, 1 Jan 2008 18:56:38 +0000 (UTC) (envelope-from root@lupin.parts-unknown.org) Received: (qmail 30998 invoked by uid 0); 1 Jan 2008 18:38:41 -0000 Received: (qmail 12019 invoked from network); 1 Jan 2008 06:55:33 -0000 Received: from qmail by qscan (mail filter); 1 Jan 2008 06:55:33 +0000 Received: from mx2.freebsd.org (69.147.83.53) by lupin.parts-unknown.org with SMTP; 1 Jan 2008 06:55:33 -0000 Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 0FFBF5CCB2; Tue, 1 Jan 2008 06:54:45 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id E8D1C16A52C; Tue, 1 Jan 2008 06:54:44 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 103EA16A49C for ; Tue, 1 Jan 2008 06:54:39 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id D8C5C13C468 for ; Tue, 1 Jan 2008 06:54:38 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so8580309waf.3 for ; Mon, 31 Dec 2007 22:54:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=UNDDGaNq+qK9j2H8tmJiDi2IH7+/nQ46F9cT4C9ccb4=; b=Jk0Ws1z+FtlBt29ovSqzpG4DMq75weAjSQganWgjBsAdl48QfqXZCeoNVj4g5jFySuSGrOIsslOX+USqb+3esYVRkcDwa7A9wXYI+sqW4fq0j8Bkikcltdno7OgUDVKKXGZI3N8l24f4aDizfWhJNrWvx6o4LlNvH4qbOV8qddA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rK/Xd2po2K91edq41HVBy5/fD+mT/cHtFD7wB/kWPcbGTITOtyXbkR4IgR/NEK9NWcX6TIi/bFAS35ZjJkA4vThBmmBOxnNkq1okSjoav8t/R/XtYWZIn1/f/pVblK2RIdakRmVLB2iea6chwuby8+MCrnz9X2XtCs/4fuC4Mj4= Received: by 10.142.215.5 with SMTP id n5mr3713133wfg.161.1199168867374; Mon, 31 Dec 2007 22:27:47 -0800 (PST) Received: by 10.142.162.20 with HTTP; Mon, 31 Dec 2007 22:27:47 -0800 (PST) Message-ID: Date: Tue, 1 Jan 2008 14:27:47 +0800 From: "Sepherosa Ziehau" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86ir2hznnd.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <86ir2hznnd.fsf@ds4.des.no> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2008 18:56:39 -0000 On Dec 29, 2007 8:33 PM, Dag-Erling Sm=F8rgrav wrote: > I upgraded my router cum firewall cum access point (soekris net4801 with > a cheap third-party ralink-based wlan adapter) from RELENG_6 to HEAD and > noticed what seems to be a regression in if_ral. After a certain amount > of use (i.e. actually having a client connected to it and transferring > data), the connection falters, and eventually the client can no longer > see even see the access point in a scan. Restarting the interface on > the router (/etc/rc.d/netif restart ral0) fixes it. I now have a cron > job that does this every five minutes. I still get occasional outages, > but all I have to do is wait a few minutes for the cron job to kick in. > > Outages are clearly related to traffic; a sure-fire way to trigger one > is to start a backup job on my laptop (rsync to my file server). I will > lose the wlan connection repeatedly until I either stop trying or run > the script with a bandwidth limit. > > des@soe ~% uname -a > FreeBSD soe.des.no 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Dec 15 20:46:2= 9 UTC 2007 des@pwd.des.no:/usr/obj/usr/src/sys/soe i386 > des@soe ~% kldstat -v > Id Refs Address Size Name > 1 18 0xc0400000 33fdfc kernel (/boot/soe/kernel) > 2 1 0xc0740000 7690 if_sis.ko (/boot/soe/if_sis.ko) > 3 2 0xc0748000 1dbe0 miibus.ko (/boot/soe/miibus.ko) > 4 1 0xc0766000 18e28 if_ral.ko (/boot/soe/if_ral.ko) > 5 4 0xc077f000 2a95c wlan.ko (/boot/soe/wlan.ko) > 6 1 0xc07aa000 2cb0 wlan_acl.ko (/boot/soe/wlan_acl.ko) > 7 1 0xc07ad000 1924 wlan_scan_ap.ko (/boot/soe/wlan_scan_ap.ko) > 8 1 0xc107f000 6000 geom_md.ko (/boot/soe/geom_md.ko) > 9 1 0xc10f9000 2000 pflog.ko (/boot/soe/pflog.ko) > 10 1 0xc10fb000 2f000 pf.ko (/boot/soe/pf.ko) > 11 4 0xc118d000 a000 netgraph.ko (/boot/soe/netgraph.ko) > 12 1 0xc119c000 3000 ng_ether.ko (/boot/soe/ng_ether.ko) > 13 1 0xc11a8000 5000 ng_pppoe.ko (/boot/soe/ng_pppoe.ko) > 14 1 0xc11ad000 4000 ng_socket.ko (/boot/soe/ng_socket.ko) > des@soe ~% grep ral0 /var/run/dmesg.boot > ral0: mem 0xa0004000-0xa0005fff irq 11 at devi= ce 10.0 on pci0 I don't whether following thingies will fix your problem: 1) rt2560.c: rt2560_setup_tx_desc() Set RT2560_{TX,TX_CIPHER}_BUSY desc flag at the end of this function, instead of at the beginning of this function. The original way _may_ confuse hardware encryption/tx engine. 2) And the rt2560_bbp_read() is not correct, it should look like following: static uint8_t rt2560_bbp_read(struct rt2560_softc *sc, uint8_t reg) { =09uint32_t val; =09int ntries; =09for (ntries =3D 0; ntries < 100; ntries++) { =09=09if (!(RAL_READ(sc, RT2560_BBPCSR) & RT2560_BBP_BUSY)) =09=09=09break; =09=09DELAY(1); =09} =09if (ntries =3D=3D 100) { =09=09device_printf(sc->sc_dev, "could not read from BBP\n"); =09=09return 0; =09} =09val =3D RT2560_BBP_BUSY | reg << 8; =09RAL_WRITE(sc, RT2560_BBPCSR, val); =09for (ntries =3D 0; ntries < 100; ntries++) { =09=09val =3D RAL_READ(sc, RT2560_BBPCSR); =09=09if (!(val & RT2560_BBP_BUSY)) =09=09=09return val & 0xff; =09=09DELAY(1); =09} =09device_printf(sc->sc_dev, "could not read from BBP\n"); =09return 0; } 3) After above fix, rt2560_set_txantenna() and rt2560_set_rxantenna() should be called after rt2560_bbp_init(), since above two function touch BBP. NOTE: without above fix, you may burn your card. Even with these in place in dfly, I still have strange TX performance regression in sta mode (drop from 20Mb/s to 3Mb/s under very well condition) on certain hardwares after 20sec~30sec TCP_STREAM netperf testing; didn't have enough time to dig, however, all of the tested hardwares stayed connected during testing (I usually run netperf stream test for 12 hours or more). Best Regards, sephe --=20 Live Free or Die _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Jan 1 18:58:35 2008 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 D86C416A476 for ; Tue, 1 Jan 2008 18:58:35 +0000 (UTC) (envelope-from root@lupin.parts-unknown.org) Received: from lupin.parts-unknown.org (lupin.cybernude.org [66.93.170.242]) by mx1.freebsd.org (Postfix) with SMTP id 5EED013C4F6 for ; Tue, 1 Jan 2008 18:58:35 +0000 (UTC) (envelope-from root@lupin.parts-unknown.org) Received: (qmail 39338 invoked by uid 0); 1 Jan 2008 18:40:02 -0000 Received: (qmail 3030 invoked from network); 1 Jan 2008 13:32:47 -0000 Received: from qmail by qscan (mail filter); 1 Jan 2008 13:32:47 +0000 Received: from mx2.freebsd.org (69.147.83.53) by lupin.parts-unknown.org with SMTP; 1 Jan 2008 13:32:47 -0000 Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 7A88C2FF90; Tue, 1 Jan 2008 13:32:32 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 5E5D216A51F; Tue, 1 Jan 2008 13:32:32 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AA7B16A46B; Tue, 1 Jan 2008 13:32:26 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 040BD13C4E3; Tue, 1 Jan 2008 13:32:25 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id C76A420A0; Tue, 1 Jan 2008 14:32:16 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.1/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id B95E9209C; Tue, 1 Jan 2008 14:32:16 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 983FC8449F; Tue, 1 Jan 2008 14:32:16 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Sepherosa Ziehau" References: <86ir2hznnd.fsf@ds4.des.no> Date: Tue, 01 Jan 2008 14:32:16 +0100 In-Reply-To: (Sepherosa Ziehau's message of "Tue\, 1 Jan 2008 14\:27\:47 +0800") Message-ID: <86abnpu0wv.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2008 18:58:35 -0000 "Sepherosa Ziehau" writes: > I don't whether following thingies will fix your problem: > [...] Can you provide a diff? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Jan 1 19:05:26 2008 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 A488C16A49C for ; Tue, 1 Jan 2008 19:05:26 +0000 (UTC) (envelope-from root@lupin.parts-unknown.org) Received: from lupin.parts-unknown.org (lupin.cybernude.org [66.93.170.242]) by mx1.freebsd.org (Postfix) with SMTP id 1931213C507 for ; Tue, 1 Jan 2008 19:05:26 +0000 (UTC) (envelope-from root@lupin.parts-unknown.org) Received: (qmail 5688 invoked by uid 0); 1 Jan 2008 18:34:35 -0000 Received: (qmail 3030 invoked from network); 1 Jan 2008 13:32:47 -0000 Received: from qmail by qscan (mail filter); 1 Jan 2008 13:32:47 +0000 Received: from mx2.freebsd.org (69.147.83.53) by lupin.parts-unknown.org with SMTP; 1 Jan 2008 13:32:47 -0000 Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 7A88C2FF90; Tue, 1 Jan 2008 13:32:32 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 5E5D216A51F; Tue, 1 Jan 2008 13:32:32 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AA7B16A46B; Tue, 1 Jan 2008 13:32:26 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 040BD13C4E3; Tue, 1 Jan 2008 13:32:25 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id C76A420A0; Tue, 1 Jan 2008 14:32:16 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.1/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id B95E9209C; Tue, 1 Jan 2008 14:32:16 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 983FC8449F; Tue, 1 Jan 2008 14:32:16 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Sepherosa Ziehau" References: <86ir2hznnd.fsf@ds4.des.no> Date: Tue, 01 Jan 2008 14:32:16 +0100 In-Reply-To: (Sepherosa Ziehau's message of "Tue\, 1 Jan 2008 14\:27\:47 +0800") Message-ID: <86abnpu0wv.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2008 19:05:26 -0000 "Sepherosa Ziehau" writes: > I don't whether following thingies will fix your problem: > [...] Can you provide a diff? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Jan 1 23:58:14 2008 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 2C19016A419 for ; Tue, 1 Jan 2008 23:58:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outM.internet-mail-service.net (outM.internet-mail-service.net [216.240.47.236]) by mx1.freebsd.org (Postfix) with ESMTP id 0D9BF13C44B for ; Tue, 1 Jan 2008 23:58:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 01 Jan 2008 15:58:13 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 592B4126DE5; Tue, 1 Jan 2008 15:58:12 -0800 (PST) Message-ID: <477AD3A1.4060401@elischer.org> Date: Tue, 01 Jan 2008 15:58:25 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Bruce Evans References: <4779697A.4050806@elischer.org> <20080101105918.I9594@delplex.bde.org> In-Reply-To: <20080101105918.I9594@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: m_freem() 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, 01 Jan 2008 23:58:14 -0000 Bruce Evans wrote: > On Mon, 31 Dec 2007, Julian Elischer wrote: > >> m_freem() would be a perfect candidate for an inline function. >> (or even macro). >> in the case where m is null, no function call would even be made... >> The whole function is only 2 lines, and it gets called once for every >> packet :-) > > On the contrary, m_freem() is a large function that is fairly unsuitable > for inlining. I just happened to count that it usually takes 180 > instructions in -current with no INVARIANTS etc. (down from 245 > instructions in ~5.2). Further counting gave 112 and 132 instructions > for it (180 was for ttcp udp input packets and 112 and 132 are for > ping packets in 2 directions). > > m_freem() is only one statement, but that statement consists mainly > of a function call to a function that is inline (m_free()). m_free() > sometimes calls m_free_ext(), which is not inline, and usually calls > uma_zfree(), which is inline, but which is just a wrapper for > uma_zfree_arg(), which is not inline. uma_zfree_arg() is very large > and thus very unsuitable for inlining. I didn't check for [nested] > inlining of its internals at the source level. At runtime it usually > calls the non-inline-function m_dtor_mbuf() which calls the non-inline > function m_tag_delete_chain(); then it calls critical_enter() and > critical_exit(). critical_exit() is fairly large and sometimes calls > thread_lock(), mi_switch() and thread_unlock(), but usually doesn't. > So the non-inline part of the call chain is usually: > > m_freem() > uma_zfree_arg() # the following is just 1 short path through this > m_dtor_mbuf() > m_tag_delete_chain() > critical_enter() > critical_exit() > > [Pause to recover from a double fault panic in critical*(). critical*() > or kdb is non-reeantrant somehwere, so tracing through critical_*() or > one of its callers in order to count instructions tends to cause panics.] > > All this is too large to inline. Inlining only the top level of it would > only make a tiny difference. It might make a positive or negative > difference, depending on whether the reduced instruction count has a larger > effect than the increased cache pressure. Generally I think it is bogus > to inline at the top level. Here inlining at the top level may win in 2 > ways: > - by avoiding the function call to the next level (and thus all function > calls) in the usual case. I think this doesn't happen here. I think it > is the usual case for the m_free_ext() call in m_free(), so inlining > m_free() is a clear win. > - by improving branch prediction. With a branch in a non-inline function, > it may be mispredicted often because different classes of callers > make it go in different ways. With branch the distributed in callers > by inlining, it can be predicted perfectly in individual callers > that don't change its direction often and/or change its direction > in predictable ways. On Athlon CPUs, mispredicting a single branch > costs the same several function calls provided the implicit branches > for all the function calls are not mispredicted. Too much inlining > is still bad. Apart from busting icaches, it can bust branch > prediction caches -- with enough distribution of branches, all > branches will be mispredicted. > > The m_freem() wrapper currently limits the icache bloat from the > m_free() inline. In RELENG_4, both m_free() and m_freem() are non-inline > and non-macro. That may be why networking in RELENG_4 is so much more > efficient than in -current ;-). (Actually it makes little difference.) Interesting.. I hadn't realised that m_free() had become an inline. It does make things more interesting. > > Bruce > _______________________________________________ > 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 Jan 2 03:07:37 2008 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 53D3816A419 for ; Wed, 2 Jan 2008 03:07:37 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id 2102813C45A for ; Wed, 2 Jan 2008 03:07:37 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so9178013waf.3 for ; Tue, 01 Jan 2008 19:07:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:content-transfer-encoding:in-reply-to:user-agent:organization:x-operation-sytem:from; bh=I9iTXpKPoCvbL8sc1t5g0mC/daVOusGhd5NxAn7tRLs=; b=sWWzYMxn8z1erc1dPhRBeB6GF/C+7NA8ZZFrxQmeE4Lz+KjBhfwQXkgxRsMDAkknZmgi3bYyCp0e4Fj4Ia2QHcC2pBHMZ4EPfwFT9ogP9pMtyJKF178wafN+Uj4rHzTF3dOY6VQkSpuWl1TIy9coNCrtj9q2p2XhxsfT5kBnSfw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:content-transfer-encoding:in-reply-to:user-agent:organization:x-operation-sytem:from; b=u78KBAHaB6LPnxbd0wg5URy72T/VTMrUAgE5tCf69pPgcSTIgSngtXCUAX2KK6qJB1Lu5HfFhgjHwt3I2Kt3cyVewwd6bPmckNZ0L/AEzIBEY08jnzdGQLY/5alwYBqFH1xWd5YiBHJAnSty1GO9C1fDFKRB4/UhfDYRFB+8bdU= Received: by 10.114.199.1 with SMTP id w1mr12849388waf.38.1199241524058; Tue, 01 Jan 2008 18:38:44 -0800 (PST) Received: from freebsd.weongyo.org ( [211.53.35.67]) by mx.google.com with ESMTPS id y11sm22234796pod.9.2008.01.01.18.38.41 (version=SSLv3 cipher=OTHER); Tue, 01 Jan 2008 18:38:43 -0800 (PST) Received: by freebsd.weongyo.org (sSMTP sendmail emulation); Wed, 2 Jan 2008 11:38:32 +0900 Date: Wed, 2 Jan 2008 11:38:31 +0900 To: Sepherosa Ziehau Message-ID: <20080102023831.GA53242@freebsd.weongyo.org> Mail-Followup-To: Sepherosa Ziehau , Dag-Erling =?UTF8?Q?Sm=F8rgrav?= , kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org References: <86ir2hznnd.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD From: Weongyo Jeong Cc: Dag-Erling =?UTF8?Q?Sm=F8rgrav?= , sam@freebsd.org, net@freebsd.org, current@freebsd.org, kevlo@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 03:07:37 -0000 On Tue, Jan 01, 2008 at 02:27:47PM +0800, Sepherosa Ziehau wrote: > On Dec 29, 2007 8:33 PM, Dag-Erling Smørgrav wrote: > > I upgraded my router cum firewall cum access point (soekris net4801 with > > a cheap third-party ralink-based wlan adapter) from RELENG_6 to HEAD and > > noticed what seems to be a regression in if_ral. After a certain amount > > of use (i.e. actually having a client connected to it and transferring > > data), the connection falters, and eventually the client can no longer > > see even see the access point in a scan. Restarting the interface on > > the router (/etc/rc.d/netif restart ral0) fixes it. I now have a cron > > job that does this every five minutes. I still get occasional outages, > > but all I have to do is wait a few minutes for the cron job to kick in. > > > > Outages are clearly related to traffic; a sure-fire way to trigger one > > is to start a backup job on my laptop (rsync to my file server). I will > > lose the wlan connection repeatedly until I either stop trying or run > > the script with a bandwidth limit. > > > > des@soe ~% uname -a > > FreeBSD soe.des.no 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Dec 15 20:46:29 UTC 2007 des@pwd.des.no:/usr/obj/usr/src/sys/soe i386 > > des@soe ~% kldstat -v > > Id Refs Address Size Name > > 1 18 0xc0400000 33fdfc kernel (/boot/soe/kernel) > > 2 1 0xc0740000 7690 if_sis.ko (/boot/soe/if_sis.ko) > > 3 2 0xc0748000 1dbe0 miibus.ko (/boot/soe/miibus.ko) > > 4 1 0xc0766000 18e28 if_ral.ko (/boot/soe/if_ral.ko) > > 5 4 0xc077f000 2a95c wlan.ko (/boot/soe/wlan.ko) > > 6 1 0xc07aa000 2cb0 wlan_acl.ko (/boot/soe/wlan_acl.ko) > > 7 1 0xc07ad000 1924 wlan_scan_ap.ko (/boot/soe/wlan_scan_ap.ko) > > 8 1 0xc107f000 6000 geom_md.ko (/boot/soe/geom_md.ko) > > 9 1 0xc10f9000 2000 pflog.ko (/boot/soe/pflog.ko) > > 10 1 0xc10fb000 2f000 pf.ko (/boot/soe/pf.ko) > > 11 4 0xc118d000 a000 netgraph.ko (/boot/soe/netgraph.ko) > > 12 1 0xc119c000 3000 ng_ether.ko (/boot/soe/ng_ether.ko) > > 13 1 0xc11a8000 5000 ng_pppoe.ko (/boot/soe/ng_pppoe.ko) > > 14 1 0xc11ad000 4000 ng_socket.ko (/boot/soe/ng_socket.ko) > > des@soe ~% grep ral0 /var/run/dmesg.boot > > ral0: mem 0xa0004000-0xa0005fff irq 11 at device 10.0 on pci0 > > I don't whether following thingies will fix your problem: > > 1) > rt2560.c: rt2560_setup_tx_desc() > Set RT2560_{TX,TX_CIPHER}_BUSY desc flag at the end of this function, > instead of at the beginning of this function. The original way _may_ > confuse hardware encryption/tx engine. > > 2) > And the rt2560_bbp_read() is not correct, it should look like following: > static uint8_t > rt2560_bbp_read(struct rt2560_softc *sc, uint8_t reg) > { > uint32_t val; > int ntries; > > for (ntries = 0; ntries < 100; ntries++) { > if (!(RAL_READ(sc, RT2560_BBPCSR) & RT2560_BBP_BUSY)) > break; > DELAY(1); > } > if (ntries == 100) { > device_printf(sc->sc_dev, "could not read from BBP\n"); > return 0; > } > > val = RT2560_BBP_BUSY | reg << 8; > RAL_WRITE(sc, RT2560_BBPCSR, val); > > for (ntries = 0; ntries < 100; ntries++) { > val = RAL_READ(sc, RT2560_BBPCSR); > if (!(val & RT2560_BBP_BUSY)) > return val & 0xff; > DELAY(1); > } > > device_printf(sc->sc_dev, "could not read from BBP\n"); > return 0; > } > > 3) > After above fix, > rt2560_set_txantenna() and rt2560_set_rxantenna() should be called > after rt2560_bbp_init(), since above two function touch BBP. NOTE: > without above fix, you may burn your card. > > Even with these in place in dfly, I still have strange TX performance > regression in sta mode (drop from 20Mb/s to 3Mb/s under very well > condition) on certain hardwares after 20sec~30sec TCP_STREAM netperf > testing; didn't have enough time to dig, however, all of the tested > hardwares stayed connected during testing (I usually run netperf > stream test for 12 hours or more). I also saw some regression in TX performance during porting malo(4). Problems were fixed after removing following lines in *_start: /* * Cancel any background scan. */ if (ic->ic_flags & IEEE80211_F_SCAN) ieee80211_cancel_scan(ic); and (optionally) if (m->m_flags & M_TXCB) ... ieee80211_process_callback(ni, m, 0); /* XXX status? ... I tested in malo(4) only not in other devices so I can't sure that this would fix regression but it worked well after patching. However, I know that this workaround isn't a fundamental sulution to fix this problem. regards, Weongyo Jeong From owner-freebsd-net@FreeBSD.ORG Wed Jan 2 08:30:04 2008 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 51ADD16A41A for ; Wed, 2 Jan 2008 08:30:04 +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 2A22613C4E3 for ; Wed, 2 Jan 2008 08:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m028U3AO055930 for ; Wed, 2 Jan 2008 08:30:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m028U3xD055923; Wed, 2 Jan 2008 08:30:03 GMT (envelope-from gnats) Date: Wed, 2 Jan 2008 08:30:03 GMT Message-Id: <200801020830.m028U3xD055923@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Benjamin Close Cc: Subject: Re: kern/118975: [bge] [patch] Broadcom 5906 not handled by FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Benjamin Close List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 08:30:04 -0000 The following reply was made to PR kern/118975; it has been noted by GNATS. From: Benjamin Close To: bug-followup@FreeBSD.org, thn@saeab.se Cc: Subject: Re: kern/118975: [bge] [patch] Broadcom 5906 not handled by FreeBSD Date: Wed, 02 Jan 2008 18:42:34 +1030 The -Current portion of this patch works like a charm under 20070102 -Current ! Cheers, Benjamin (benjsc) From owner-freebsd-net@FreeBSD.ORG Wed Jan 2 13:18:39 2008 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 1A35116A41B for ; Wed, 2 Jan 2008 13:18:39 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.229]) by mx1.freebsd.org (Postfix) with ESMTP id BC41A13C46B for ; Wed, 2 Jan 2008 13:18:38 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so845795nzf.13 for ; Wed, 02 Jan 2008 05:18:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=p4ncwgVfJjUwvSdaY7rjdiIX/ZZlLQD51bPGlrZI4jI=; b=YV9zt34xXtro3SUOF8a2wvgV0pve5y/bFUpv0k9HauLMicg8xMqgNMgILqbwjyVSLwEdj69xLCHivbma+c2BRTvNFiBaTTv0ivoXMMBqlHAYH/ql+pi47Ioeq1sX+6dUSTtV4zO1b5xXLfvswh8hVtfxyA2o9eCyyq1GLQg/B8s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Zjqt3EhwtjsSfxhf6Y5hzmtdaV8BpKxDtpfYeAOluNwgBylCOn6COPOmKTh3a4zHi5E8c8j0yJFfFgZ5g9b85+dKH1SWfSUbUeRiaYEk1RVQmhYwjYeKNC7/huf2eHOiwS4mfAUZp1z4qgSW1CIE9edxQq2y5ZomsNh+HOwM+gM= Received: by 10.142.108.14 with SMTP id g14mr3444922wfc.52.1199279917515; Wed, 02 Jan 2008 05:18:37 -0800 (PST) Received: by 10.142.162.20 with HTTP; Wed, 2 Jan 2008 05:18:37 -0800 (PST) Message-ID: Date: Wed, 2 Jan 2008 21:18:37 +0800 From: "Sepherosa Ziehau" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86abnpu0wv.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 13:18:39 -0000 On Jan 1, 2008 9:32 PM, Dag-Erling Sm=F8rgrav wrote: > "Sepherosa Ziehau" writes: > > I don't whether following thingies will fix your problem: > > [...] > > Can you provide a diff? http://people.freebsd.org/~sephe/rt2560_test.diff Hope it will have some effect. Best Regards, sephe --=20 Live Free or Die From owner-freebsd-net@FreeBSD.ORG Wed Jan 2 13:28:31 2008 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 EAEAC16A419 for ; Wed, 2 Jan 2008 13:28:31 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7DDA613C4E3 for ; Wed, 2 Jan 2008 13:28:31 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so9884411pyb.10 for ; Wed, 02 Jan 2008 05:28:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=e8HDWh4hpLn9Hz87T0deh8k4k/QK2ShmvBOwXITVZ6o=; b=Y3c3P4o+/YFT4nAgf8CvtpUOenry/WCnVamP1x9pn+/QpPjF8KTqDDkJ0GF9RatqkQTDoPzH0zSwDwQAmqZhuUgqhEP0xf+tG0eQToX6mVNnwXB+yghAVk5jJTHnH93uNauR1b4JXYT9AUqDI3P60fPbh/2ducb0673v4J2kd/4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dXDAhD5C3KzHs1rfWLuNMXOQ9J784cg2A04P+Ch8ClcogcohziYolLMNJWo2aqd0u7DHYWir4Z6s+wmtKeWULSwesn42HReMULC67Auz5gWHnloc/zHnR2mOXiyCrhuWGQL/noJ6oMZb/C+2hd8gKGwkbCLnddjloVrAmVXHDQI= Received: by 10.142.132.2 with SMTP id f2mr3893856wfd.221.1199280510335; Wed, 02 Jan 2008 05:28:30 -0800 (PST) Received: by 10.142.162.20 with HTTP; Wed, 2 Jan 2008 05:28:30 -0800 (PST) Message-ID: Date: Wed, 2 Jan 2008 21:28:30 +0800 From: "Sepherosa Ziehau" To: "Weongyo Jeong" In-Reply-To: <20080102023831.GA53242@freebsd.weongyo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <86ir2hznnd.fsf@ds4.des.no> <20080102023831.GA53242@freebsd.weongyo.org> Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , sam@freebsd.org, net@freebsd.org, current@freebsd.org, kevlo@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 13:28:32 -0000 On Jan 2, 2008 10:38 AM, Weongyo Jeong wrote: > > > Even with these in place in dfly, I still have strange TX performance > > regression in sta mode (drop from 20Mb/s to 3Mb/s under very well > > condition) on certain hardwares after 20sec~30sec TCP_STREAM netperf > > testing; didn't have enough time to dig, however, all of the tested > > hardwares stayed connected during testing (I usually run netperf > > stream test for 12 hours or more). > > I also saw some regression in TX performance during porting malo(4). Have you tried to turn bgscan off completely? My problem seems to be hardware (I suspect rf) related. The TX performance regression does not happen with UDP stream which only uses 802.11 ack, i.e. hardware seems to have touble to switch between data RX and data TX at high freq. > Problems were fixed after removing following lines in *_start: > > /* > * Cancel any background scan. > */ > if (ic->ic_flags & IEEE80211_F_SCAN) > ieee80211_cancel_scan(ic); > > and (optionally) > > if (m->m_flags & M_TXCB) > ... > ieee80211_process_callback(ni, m, 0); /* XXX status? > ... I don't think you can remove TXCB processing in drivers :) Best Regards, sephe -- Live Free or Die From owner-freebsd-net@FreeBSD.ORG Wed Jan 2 14:39:48 2008 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 3A3DD16A41A for ; Wed, 2 Jan 2008 14:39:48 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mx1.freebsd.org (Postfix) with ESMTP id 14BB513C442 for ; Wed, 2 Jan 2008 14:39:48 +0000 (UTC) (envelope-from rrs@cisco.com) X-IronPort-AV: E=Sophos;i="4.24,234,1196668800"; d="scan'208";a="9240009" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 02 Jan 2008 06:11:22 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m02EBM0Y016537; Wed, 2 Jan 2008 06:11:22 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m02EBLjC027279; Wed, 2 Jan 2008 14:11:21 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Jan 2008 06:11:21 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Jan 2008 06:11:20 -0800 Message-ID: <477B9AFB.1070806@cisco.com> Date: Wed, 02 Jan 2008 09:08:59 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alfred Perlstein References: <476061FD.8050500@elischer.org> <20071212225014.GY61429@elvis.mu.org> <47606B30.3020508@elischer.org> <20071212231638.GB61429@elvis.mu.org> In-Reply-To: <20071212231638.GB61429@elvis.mu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jan 2008 14:11:20.0945 (UTC) FILETIME=[597E2610:01C84D49] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=420; t=1199283082; x=1200147082; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20bikeshed=20for=20all! |Sender:=20; bh=MY58bJ8o13Srw6OVbr65vtYur7hmAH3BJiieF1JaJL4=; b=ufiy3NE3ZKAemYJ+f8D9ekSDg9IypBC+INR9IaUgp6BtWLnZxTqXi5tHlu Dpp76UzxHgn5Luuz1JMZcS+OsiFS0TBXm9Mgmx46k0Lo5e2n/Z9vMKMVsdWo HtCI4cmaMV; Authentication-Results: sj-dkim-4; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: FreeBSD Net , Julian Elischer Subject: Re: bikeshed for all! 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, 02 Jan 2008 14:39:48 -0000 Alfred Perlstein wrote: > * Julian Elischer [071212 15:13] wrote: > >>Alfred Perlstein wrote: >> >>>try using "instance". >>> >>>"Oh I'm going to use the FOO routing instance." >> >>what do Juniper call it? > > > "Instance" and "vrf". > VRF is the same thing we call it at Cisco :-) R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Wed Jan 2 15:00:59 2008 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 56B9816A417 for ; Wed, 2 Jan 2008 15:00:59 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.freebsd.org (Postfix) with ESMTP id 328FA13C459 for ; Wed, 2 Jan 2008 15:00:59 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JA55W-000Oky-8A for freebsd-net@freebsd.org; Wed, 02 Jan 2008 15:00:58 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JA55U-0000U1-ES for freebsd-net@freebsd.org; Thu, 03 Jan 2008 00:00:56 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18299.42791.826406.76763@roam.psg.com> Date: Thu, 3 Jan 2008 00:00:55 +0900 To: FreeBSD Net Subject: ath0 Ierrs 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, 02 Jan 2008 15:00:59 -0000 i seem to be loggin massive errors on an ath in hostap mode with only two wireless clients. mtu is set low as the tun0 ppoe over ntt B Flets on vr0 recommends it. wireless on the two clients is set to mtu of 1454 too. seeking pointers on how to debug. randy --- # netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll vr0 1500 00:00:24:c8:b3:28 20300694 0 9586690 0 0 vr1 1500 00:00:24:c8:b3:29 0 0 8495 0 0 vr2 1454 00:00:24:c8:b3:2a 1470 0 14571 0 0 vr3 1454 00:00:24:c8:b3:2b 144471 0 289752 0 0 ath0 1454 00:0b:6b:83:59:25 9333193 9765589 19873060 1729 0 lo0 16384 96360 0 96360 0 0 lo0 16384 fe80:6::1 fe80:6::1 0 - 0 - - lo0 16384 localhost ::1 0 - 0 - - lo0 16384 your-net localhost 96362 - 96362 - - bridg 1500 6a:fe:c7:ad:96:89 9476742 0 20046340 0 0 bridg 1500 192.168.0.0 soek0 14920 - 82683 - - tun0 1454 20247165 0 9582931 0 0 tun0 1454 210.138.216.5 50.216.138.210.bn 306221 - 180432 - - config is .----------------. | | | b ---ath0| | r | 192.168.0.0/24 ext iij | i --- vr1| PPP/NAT ---|vr0--- d | LAN hosts & WAN | g --- vr2| | e | DHCP Clients | 0 --- vr3| | | `----------------' # ifconfig -a vr0: flags=8843 metric 0 mtu 1500 options=b ether 00:00:24:c8:b3:28 media: Ethernet autoselect (100baseTX ) status: active vr1: flags=8943 metric 0 mtu 1500 options=9 ether 00:00:24:c8:b3:29 media: Ethernet autoselect (none) status: no carrier vr2: flags=8943 metric 0 mtu 1454 options=9 ether 00:00:24:c8:b3:2a media: Ethernet autoselect (100baseTX ) status: active vr3: flags=8943 metric 0 mtu 1454 options=9 ether 00:00:24:c8:b3:2b media: Ethernet autoselect (100baseTX ) status: active ath0: flags=8943 metric 0 mtu 1454 ether 00:0b:6b:83:59:25 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect ) status: associated ssid rgnet-aden channel 11 (2462 Mhz 11g) bssid 00:0b:6b:83:59:25 authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpower 31.5 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 protmode CTS burst dtimperiod 1 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 bridge0: flags=8843 metric 0 mtu 1500 ether 6a:fe:c7:ad:96:89 inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: ath0 flags=143 ifmaxaddr 0 port 5 priority 128 path cost 370370 member: vr3 flags=143 ifmaxaddr 0 port 4 priority 128 path cost 200000 member: vr2 flags=143 ifmaxaddr 0 port 3 priority 128 path cost 200000 member: vr1 flags=143 ifmaxaddr 0 port 2 priority 128 path cost 55 tun0: flags=8051 metric 0 mtu 1454 inet 210.138.216.50 --> 210.149.34.66 netmask 0xffffffff Opened by PID 566 From owner-freebsd-net@FreeBSD.ORG Wed Jan 2 16:17:03 2008 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 22DF516A4A7; Wed, 2 Jan 2008 16:17:03 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id C05BF13C4EB; Wed, 2 Jan 2008 16:17:02 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id ACF2120A0; Wed, 2 Jan 2008 17:16:53 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.1/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 996A42049; Wed, 2 Jan 2008 17:16:53 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 49DA0844CD; Wed, 2 Jan 2008 17:16:53 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Sepherosa Ziehau" References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> Date: Wed, 02 Jan 2008 17:16:53 +0100 In-Reply-To: (Sepherosa Ziehau's message of "Wed\, 2 Jan 2008 21\:18\:37 +0800") Message-ID: <86prwkqk22.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 16:17:03 -0000 "Sepherosa Ziehau" writes: > http://people.freebsd.org/~sephe/rt2560_test.diff Thank you, I'll try that. Could you explain what the RT2560_BBP_BUSY loop is about? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-net@FreeBSD.ORG Wed Jan 2 19:14:11 2008 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 823DB16A419; Wed, 2 Jan 2008 19:14:11 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 3639E13C455; Wed, 2 Jan 2008 19:14:11 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 43EEF20A0; Wed, 2 Jan 2008 20:14:03 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.1/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 2CD9B2089; Wed, 2 Jan 2008 20:14:03 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 14D2784490; Wed, 2 Jan 2008 20:14:03 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Sepherosa Ziehau" References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> Date: Wed, 02 Jan 2008 20:14:03 +0100 In-Reply-To: (Sepherosa Ziehau's message of "Wed\, 2 Jan 2008 21\:18\:37 +0800") Message-ID: <86abnovy4k.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 19:14:11 -0000 "Sepherosa Ziehau" writes: > http://people.freebsd.org/~sephe/rt2560_test.diff > > Hope it will have some effect. I built a new kernel with the patch applied, and it seems to help, though it's a bit early to say for sure. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-net@FreeBSD.ORG Wed Jan 2 22:46:16 2008 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 E11E616A421 for ; Wed, 2 Jan 2008 22:46:15 +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 5CE8913C46E for ; Wed, 2 Jan 2008 22:46:15 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 81323 invoked from network); 2 Jan 2008 22:11:31 -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 ; 2 Jan 2008 22:11:31 -0000 Message-ID: <477C1434.80106@freebsd.org> Date: Wed, 02 Jan 2008 23:46:12 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Tiffany Snyder References: <43B45EEF.6060800@x-trader.de> <43B47CB5.3C0F1632@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Routing SMP benefit 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, 02 Jan 2008 22:46:16 -0000 Tiffany Snyder wrote: > Hi Andre, > are those numbers for small (64 bytes) packets? Good job on pushing > the base numbers higher on the same HW. Yes, 64 bytes. Haven't measured lately, but I assume PCI-E hardware instead of PCI-X could push quite some more. > What piqued my attention was the note that our forwarding > performance doesn't scale with multiple CPUs. Which means there's a lot of > work to be done :-) Have we taken a look at OpenSolaris' Surya > (http://www.opensolaris.org/os/community/networking/surya-design.pdf) > project? They allow multiple readers/single writer on the radix_node_head > (and not a mutex as we do) and we may be able to do the same to gain some > parallelism. There are other things in Surya that exploit multiple CPUs. > It's definitely worth a read. DragonFlyBSD seems to achieve parallelism by > classifying packet as flows and then redirecting the flows to different > CPUs. OpenSolaris also does something similar. We can definitely think along > those lines. So far the PPS rate limit has primarily been the cache miss penalties on the packet access. Multiple CPUs can help here of course for bi- directional traffic. Hardware based packet header cache prefetching as done by some embedded MIPS based network processors at least doubles the performance. Intel has something like this for a couple of chipset and network chip combinations. We don't support that feature yet though. Many of the things you mention here are planned for FreeBSD 8.0 in the same or different form. Work in progress is the separation of the ARP table from kernel routing table. If we can prevent references to radix nodes generally almost all locking can be done away with. Instead only a global rmlock (read-mostly) could govern the entire routing table. Obtaining the rmlock for reading is essentially free. Table changes are very infrequent compared to lookups (like 700,000 to 300-400) in default free Internet routing. The radix trie nodes are rather big and could use some more trimming to make the fit a single cache line. I've already removed some stuff a couple of years ago and more can be done. It's very important to keep this in mind: "profile, don't speculate". For example while the DragonFly model may seem good in theory it so far did not show itself to be faster. Back when I had the Agilent N2X network tester DFBSD was the poorest performer in the test set of FreeBSD, OpenBSD and DFBSD. Haven't tested Solaris yet, and neither retested the others, but until that is done we should not jump to conclusions yet. At the time we were more than two to three times faster than the other BSDs. > NOTE: > 1) I said multiple instead of dual CPUs on purpose. > 2) I mentioned OpenSolaris and DragonFlyBSD as examples and to acknowledge > the work they are doing and to show that FreeBSD is far behind and is losing > it's lustre on continuing to be the networking platform of choice. Like I said. Don't jump to conclusions without real testing and profiling. Reality may turn out to be different from theory. ;) -- Andre > Thanks, > > Tiffany. > > > On 12/29/05, Andre Oppermann wrote: > >> Markus Oestreicher wrote: >>> Currently running a few routers on 5-STABLE I have read the >>> recent changes in the network stack with interest. >> You should run 6.0R. It contains many improvements over 5-STABLE. >> >>> A few questions come to my mind: >>> >>> - Can a machine that mainly routes packets between two em(4) >>> interfaces benefit from a second CPU and SMP kernel? Can both >>> CPUs process packets from the same interface in parallel? >> My testing has shown that a machine can benefit from it but not >> much in the forwarding performance. The main benefit is the >> prevention of lifelock if you have very high packet loads. The >> second CPU on SMP keeps on doing all userland tasks and running >> routing protocols. Otherwise your BGP sessions or OSPF hellos >> would stop and remove you from the routing cloud. >> >>> - From reading the lists it appears that net.isr.direct >>> and net.ip.fastforwarding are doing similar things. Should >>> they be used together or rather not? >> net.inet.ip.fastforwarding has precedence over net.isr.direct and >> enabling both at the same doesn't gain you anything. Fastforwarding >> is about 30% faster than all other methods available, including >> polling. On my test machine with two em(4) and an AMD Opteron 852 >> (2.6GHz) I can route 580'000 pps with zero packet loss on -CURRENT. >> An upcoming optimization that will go into -CURRENT in the next >> few days pushes that to 714'000 pps. Futher optimizations are >> underway to make a stock kernel do close to or above 1'000'000 pps >> on the same hardware. >> >> -- >> 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" >> > _______________________________________________ > 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 Jan 2 23:00:08 2008 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 BA50516A417; Wed, 2 Jan 2008 23:00:08 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 8F7FE13C455; Wed, 2 Jan 2008 23:00:08 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 2136382BEC; Wed, 2 Jan 2008 18:00:08 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 02 Jan 2008 18:00:08 -0500 X-Sasl-enc: Dm5wF5UAG3ELkHX9Ly5TBPv+E8N6JHR71dRc7KQu/JX1 1199314807 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 77F6525D94; Wed, 2 Jan 2008 18:00:07 -0500 (EST) Message-ID: <477C1776.2080002@FreeBSD.org> Date: Wed, 02 Jan 2008 23:00:06 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Andre Oppermann References: <43B45EEF.6060800@x-trader.de> <43B47CB5.3C0F1632@freebsd.org> <477C1434.80106@freebsd.org> In-Reply-To: <477C1434.80106@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Tiffany Snyder Subject: Re: Routing SMP benefit 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, 02 Jan 2008 23:00:08 -0000 Andre Oppermann wrote: > So far the PPS rate limit has primarily been the cache miss penalties > on the packet access. Multiple CPUs can help here of course for bi- > directional traffic. Hardware based packet header cache prefetching as > done by some embedded MIPS based network processors at least doubles the > performance. Intel has something like this for a couple of chipset and > network chip combinations. We don't support that feature yet though. What sort of work is needed in order to support header prefetch? > > Many of the things you mention here are planned for FreeBSD 8.0 in the > same or different form. Work in progress is the separation of the ARP > table from kernel routing table. If we can prevent references to radix > nodes generally almost all locking can be done away with. Instead only > a global rmlock (read-mostly) could govern the entire routing table. > Obtaining the rmlock for reading is essentially free. This is exactly what I'm thinking, this feels like the right way forward. A single rwlock should be fine, route table updates should generally only be happening from one process, and thus a single thread, at any given time. > Table changes > are very infrequent compared to lookups (like 700,000 to 300-400) in > default free Internet routing. The radix trie nodes are rather big > and could use some more trimming to make the fit a single cache line. > I've already removed some stuff a couple of years ago and more can be > done. > > It's very important to keep this in mind: "profile, don't speculate". Beware though that functionality isn't sacrificed at the expense of this. For example it would be very, very useful to be able to merge the multicast routing implementation with the unicast -- with the proviso of course that mBGP requires that RPF can be performed with a separate set of FIB entries from the unicast FIB. Of course if next-hops themselves are held in a container separately referenced from the radix node, such as a simple linked list as per the OpenBSD code. If we ensure the parent radix trie node object fits in a cache line, then that's fine. [I am looking at some stuff in the dynamic/ad-hoc/mesh space which is really going to need support for multipath similar to this.] later BMS From owner-freebsd-net@FreeBSD.ORG Thu Jan 3 00:01:41 2008 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 C21EF16A420 for ; Thu, 3 Jan 2008 00:01:41 +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 2426A13C45D for ; Thu, 3 Jan 2008 00:01:40 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 81840 invoked from network); 2 Jan 2008 23:26:56 -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 ; 2 Jan 2008 23:26:56 -0000 Message-ID: <477C25E2.4080303@freebsd.org> Date: Thu, 03 Jan 2008 01:01:38 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <43B45EEF.6060800@x-trader.de> <43B47CB5.3C0F1632@freebsd.org> <477C1434.80106@freebsd.org> <477C1776.2080002@FreeBSD.org> In-Reply-To: <477C1776.2080002@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Tiffany Snyder Subject: Re: Routing SMP benefit 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, 03 Jan 2008 00:01:41 -0000 Bruce M. Simpson wrote: > Andre Oppermann wrote: >> So far the PPS rate limit has primarily been the cache miss penalties >> on the packet access. Multiple CPUs can help here of course for bi- >> directional traffic. Hardware based packet header cache prefetching as >> done by some embedded MIPS based network processors at least doubles the >> performance. Intel has something like this for a couple of chipset and >> network chip combinations. We don't support that feature yet though. > > What sort of work is needed in order to support header prefetch? Extracting the documentation out of Intel for a first step. It's called Direct Cache Access (DCA). At least in the Linux implementation it has been intermingled with I/OAT which is an asynchronous memory controller based DMA copy mechanism. Don't know if they really have to be together. The idea of DCA is to cause the memory controller upon DMA'ing a packet into main memory to also load it into the CPU cache(s) right away. For packet forwarding the first 128 bytes are sufficient. For server applications and TCP it may be beneficial to prefetch the whole packet. May cause some considerable cache pollution though depending on usage. Some pointers: http://www.stanford.edu/group/comparch/papers/huggahalli05.pdf http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=tree;f=drivers/dca;hb=HEAD http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=tree;f=drivers/dma;hb=HEAD http://download.intel.com/technology/comms/perfnet/download/ServerNetworkIOAccel.pdf http://download.intel.com/design/network/prodbrf/317796.pdf >> Many of the things you mention here are planned for FreeBSD 8.0 in the >> same or different form. Work in progress is the separation of the ARP >> table from kernel routing table. If we can prevent references to radix >> nodes generally almost all locking can be done away with. Instead only >> a global rmlock (read-mostly) could govern the entire routing table. >> Obtaining the rmlock for reading is essentially free. > > This is exactly what I'm thinking, this feels like the right way forward. > > A single rwlock should be fine, route table updates should generally > only be happening from one process, and thus a single thread, at any > given time. rmlocks are even faster and the change to use ratio is also quite right. >> Table changes >> are very infrequent compared to lookups (like 700,000 to 300-400) in >> default free Internet routing. The radix trie nodes are rather big >> and could use some more trimming to make the fit a single cache line. >> I've already removed some stuff a couple of years ago and more can be >> done. >> >> It's very important to keep this in mind: "profile, don't speculate". > Beware though that functionality isn't sacrificed at the expense of this. > > For example it would be very, very useful to be able to merge the > multicast routing implementation with the unicast -- with the proviso of > course that mBGP requires that RPF can be performed with a separate set > of FIB entries from the unicast FIB. > > Of course if next-hops themselves are held in a container separately > referenced > from the radix node, such as a simple linked list as per the OpenBSD code. Haven't looked at the multicast code so I can't comment. The other stuff is just talk so far. No work in progress, at least from my side. > If we ensure the parent radix trie node object fits in a cache line, > then that's fine. > > [I am looking at some stuff in the dynamic/ad-hoc/mesh space which is > really going to need support for multipath similar to this.] I was looking at some parallel forwarding table for fastforward that is highly optimized for IPv4 and cache efficiency. It was supposed to be 8-bit stride based (256-ary) with SSE based multi segment longest prefix match updates. Never managed to this past the design state though. And it's not one of the pressing issues. The radix trie is pretty efficient though for being architecture independent. Even though the depth and variety in destination addresses matters it never really turned out to become bottleneck in my profile at the time. It does have its limitations though becoming more apparent at very high PPS and very large routing tables as in the DFZ. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Jan 3 01:36:12 2008 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 A512616A418 for ; Thu, 3 Jan 2008 01:36:12 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191]) by mx1.freebsd.org (Postfix) with ESMTP id 7481C13C44B for ; Thu, 3 Jan 2008 01:36:11 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so5929659rvb.43 for ; Wed, 02 Jan 2008 17:36:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=BHum5ecSuowLg1BbfOV8neI2cHvy+rJGIHz5ZIKhx84=; b=EHMOFxRLJBUDmNQeIeA44A2l9ZNePBrawtaB3xjf0jzucrEyQM1BiVXsaviIrmucHIKe3L3fuTOgfA3TJnF/neOupghUo90BjuVs9SgcuIJBSdUSDBxC4tiaoIVPeLhRLbKhlGE+2WZpyOl0esbL6R3fnrcuyqR9uFYidtw1gBU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=A1fEPKheKeHucOlNTVVX+zncEd6nSgFhJgalFtTa3hs8BzZOIo3VkM2EWBlg3wFemNntz11Wkf7nFcBfQ6XuccRuYNAmdoxPfbC5Qsd/iAz/URMqXSbLRKS8IF06MIKNoNCZ4Jbca6H5iF4W9CTG8FnYntHj4bsZH+uk8rSxz50= Received: by 10.142.154.20 with SMTP id b20mr4355611wfe.172.1199324170528; Wed, 02 Jan 2008 17:36:10 -0800 (PST) Received: by 10.142.162.20 with HTTP; Wed, 2 Jan 2008 17:36:10 -0800 (PST) Message-ID: Date: Thu, 3 Jan 2008 09:36:10 +0800 From: "Sepherosa Ziehau" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86prwkqk22.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> <86prwkqk22.fsf@ds4.des.no> Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 01:36:12 -0000 On Jan 3, 2008 12:16 AM, Dag-Erling Sm=F8rgrav wrote: > "Sepherosa Ziehau" writes: > > http://people.freebsd.org/~sephe/rt2560_test.diff > > Thank you, I'll try that. > > Could you explain what the RT2560_BBP_BUSY loop is about? bbp read involves one write to RT2560_BBPCSR, while this register should not be touched until its RT2560_BBP_BUSY bit is off (as according to Ralink's linux driver) Best Regards, sephe --=20 Live Free or Die From owner-freebsd-net@FreeBSD.ORG Thu Jan 3 04:53:07 2008 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 ACB5616A417 for ; Thu, 3 Jan 2008 04:53:07 +0000 (UTC) (envelope-from james.juran@baesystems.com) Received: from dmzmta101.na.baesystems.com (dmzmta101.na.baesystems.com [149.32.252.101]) by mx1.freebsd.org (Postfix) with ESMTP id 6B1A713C461 for ; Thu, 3 Jan 2008 04:53:07 +0000 (UTC) (envelope-from james.juran@baesystems.com) Received: from BLUMS0034.bluelnk.net (blums0034.bluelnk.net [10.40.96.55]) by dmzmta101.na.baesystems.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m0334bmY010494 for ; Wed, 2 Jan 2008 22:04:38 -0500 Received: from usdmta003.na.baesystems.com ([10.40.96.59]) by BLUMS0034.bluelnk.net with InterScan Message Security Suite; Wed, 02 Jan 2008 22:06:54 -0500 Received: from GLDMS00006.goldlnk.rootlnka.net ([10.44.64.12]) by usdmta003.na.baesystems.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m03350wj017071 for ; Wed, 2 Jan 2008 22:05:00 -0500 Received: from GLDMS00013.goldlnk.rootlnka.net ([10.44.64.9]) by GLDMS00006.goldlnk.rootlnka.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Jan 2008 22:06:54 -0500 Received: from 10.47.14.220 ([10.47.14.220]) by GLDMS00013.goldlnk.rootlnka.net ([10.44.64.16]) via Exchange Front-End Server webmail.na.baesystems.com ([10.44.64.12]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Jan 2008 03:06:53 +0000 Received: from big.juranfamily.org by webmail.na.baesystems.com; 02 Jan 2008 22:06:53 -0500 From: James Juran To: freebsd-net@freebsd.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: BAE Systems Information Technology Date: Wed, 02 Jan 2008 22:06:53 -0500 Message-Id: <1199329613.2807.8.camel@big.juranfamily.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 (2.12.2-2.fc8) X-OriginalArrivalTime: 03 Jan 2008 03:06:54.0050 (UTC) FILETIME=[B1627C20:01C84DB5] Subject: unp_connect() locking problems with early returns 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, 03 Jan 2008 04:53:07 -0000 There are two early returns in unp_connect() that need to re-acquire the UNP global lock before returning. This program will trigger a panic on a WITNESS-enabled system. I tested on the December snapshot of CURRENT-8.0, but the same problem occurs in RELENG_7. #include #include #include #include #include int main(void) { int s; struct sockaddr_un un; s = socket(PF_LOCAL, SOCK_STREAM, 0); if (s == -1) { perror("socket"); exit(1); } memset(&un, 0, sizeof(un)); un.sun_family = AF_UNIX; if ((connect(s, (struct sockaddr *)&un, 2)) == -1) { perror("connect"); exit(1); } return 0; } I believe this patch will fix the problem, but unfortunately I do not have time to test it. Could someone please try this out? Instead of this approach, it may be possible to move the unlocking to after the early returns are done, but I have not analyzed what impact this would have. Index: uipc_usrreq.c =================================================================== RCS file: /home/ncvs/src/sys/kern/uipc_usrreq.c,v retrieving revision 1.210 diff -u -p -r1.210 uipc_usrreq.c --- uipc_usrreq.c 1 Jan 2008 01:46:42 -0000 1.210 +++ uipc_usrreq.c 3 Jan 2008 02:53:51 -0000 @@ -1129,13 +1129,16 @@ unp_connect(struct socket *so, struct so KASSERT(unp != NULL, ("unp_connect: unp == NULL")); len = nam->sa_len - offsetof(struct sockaddr_un, sun_path); - if (len <= 0) + if (len <= 0) { + UNP_GLOBAL_WLOCK(); return (EINVAL); + } strlcpy(buf, soun->sun_path, len + 1); UNP_PCB_LOCK(unp); if (unp->unp_flags & UNP_CONNECTING) { UNP_PCB_UNLOCK(unp); + UNP_GLOBAL_WLOCK(); return (EALREADY); } unp->unp_flags |= UNP_CONNECTING; -- James Juran Lead Secure Systems Engineer BAE Systems Information Technology Information Assurance Group XTS Operating Systems james.juran@baesystems.com From owner-freebsd-net@FreeBSD.ORG Thu Jan 3 09:48:05 2008 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 55B5A16A421 for ; Thu, 3 Jan 2008 09:48:05 +0000 (UTC) (envelope-from fazaeli@sepehrs.com) Received: from sepehrs.com (sepehrs.com [213.217.59.98]) by mx1.freebsd.org (Postfix) with ESMTP id 89F9113C45D for ; Thu, 3 Jan 2008 09:48:04 +0000 (UTC) (envelope-from fazaeli@sepehrs.com) Received: from [192.168.1.180] ([192.168.1.180]) by sepehrs.com (8.13.6/8.13.6) with ESMTP id m03D9TK6008581; Thu, 3 Jan 2008 13:09:30 GMT (envelope-from fazaeli@sepehrs.com) Message-ID: <477CAEB5.5070305@sepehrs.com> Date: Thu, 03 Jan 2008 13:15:25 +0330 From: "H.fazaeli" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Tiffany Snyder References: <43B45EEF.6060800@x-trader.de> <43B47CB5.3C0F1632@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sepehr-MailScanner-Information: Please contact the ISP for more information X-Sepehr-MailScanner: Found to be clean X-Sepehr-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.921, required 5, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60, DATE_IN_PAST_03_06 0.48) X-MailScanner-From: fazaeli@sepehrs.com X-Spam-Status: No Cc: freebsd-net@freebsd.org Subject: Re: Routing SMP benefit 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, 03 Jan 2008 09:48:05 -0000 Hi all Where are 'those numbers' you are referring to? have I missed some message in the thread? Tiffany Snyder wrote: > Hi Andre, > are those numbers for small (64 bytes) packets? Good job on pushing > the base numbers higher on the same HW. > > What piqued my attention was the note that our forwarding > performance doesn't scale with multiple CPUs. Which means there's a lot of > work to be done :-) Have we taken a look at OpenSolaris' Surya > (http://www.opensolaris.org/os/community/networking/surya-design.pdf) > project? They allow multiple readers/single writer on the radix_node_head > (and not a mutex as we do) and we may be able to do the same to gain some > parallelism. There are other things in Surya that exploit multiple CPUs. > It's definitely worth a read. DragonFlyBSD seems to achieve parallelism by > classifying packet as flows and then redirecting the flows to different > CPUs. OpenSolaris also does something similar. We can definitely think along > those lines. > > NOTE: > 1) I said multiple instead of dual CPUs on purpose. > 2) I mentioned OpenSolaris and DragonFlyBSD as examples and to acknowledge > the work they are doing and to show that FreeBSD is far behind and is losing > it's lustre on continuing to be the networking platform of choice. > > Thanks, > > Tiffany. > > > On 12/29/05, Andre Oppermann wrote: > > >> Markus Oestreicher wrote: >> >>> Currently running a few routers on 5-STABLE I have read the >>> recent changes in the network stack with interest. >>> >> You should run 6.0R. It contains many improvements over 5-STABLE. >> >> >>> A few questions come to my mind: >>> >>> - Can a machine that mainly routes packets between two em(4) >>> interfaces benefit from a second CPU and SMP kernel? Can both >>> CPUs process packets from the same interface in parallel? >>> >> My testing has shown that a machine can benefit from it but not >> much in the forwarding performance. The main benefit is the >> prevention of lifelock if you have very high packet loads. The >> second CPU on SMP keeps on doing all userland tasks and running >> routing protocols. Otherwise your BGP sessions or OSPF hellos >> would stop and remove you from the routing cloud. >> >> >>> - From reading the lists it appears that net.isr.direct >>> and net.ip.fastforwarding are doing similar things. Should >>> they be used together or rather not? >>> >> net.inet.ip.fastforwarding has precedence over net.isr.direct and >> enabling both at the same doesn't gain you anything. Fastforwarding >> is about 30% faster than all other methods available, including >> polling. On my test machine with two em(4) and an AMD Opteron 852 >> (2.6GHz) I can route 580'000 pps with zero packet loss on -CURRENT. >> An upcoming optimization that will go into -CURRENT in the next >> few days pushes that to 714'000 pps. Futher optimizations are >> underway to make a stock kernel do close to or above 1'000'000 pps >> on the same hardware. >> >> -- >> 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" >> >> > _______________________________________________ > 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" > > > > -- With best regards. Hooman Fazaeli Sepehr S. T. Co. Ltd. From owner-freebsd-net@FreeBSD.ORG Thu Jan 3 11:02:37 2008 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 9393816A421 for ; Thu, 3 Jan 2008 11:02:37 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B485213C459; Thu, 3 Jan 2008 11:02:36 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <477CC0CD.7030404@FreeBSD.org> Date: Thu, 03 Jan 2008 12:02:37 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "H.fazaeli" References: <43B45EEF.6060800@x-trader.de> <43B47CB5.3C0F1632@freebsd.org> <477CAEB5.5070305@sepehrs.com> In-Reply-To: <477CAEB5.5070305@sepehrs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Tiffany Snyder Subject: Re: Routing SMP benefit 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, 03 Jan 2008 11:02:37 -0000 H.fazaeli wrote: > Hi all > > Where are 'those numbers' you are referring to? have I missed some message > in the thread? Check the date below, Tiffany replied to an old message from 2 years ago for some reason. Kris >> Thanks, >> >> Tiffany. >> >> >> On 12/29/05, Andre Oppermann wrote: From owner-freebsd-net@FreeBSD.ORG Thu Jan 3 08:20:43 2008 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 5DA9F16A418; Thu, 3 Jan 2008 08:20:43 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from neo.samodelkin.net (samodelkin.net [195.62.0.66]) by mx1.freebsd.org (Postfix) with ESMTP id EE30313C457; Thu, 3 Jan 2008 08:20:42 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: by neo.samodelkin.net (Postfix, from userid 10117) id 030F31727D; Thu, 3 Jan 2008 13:52:14 +0600 (NOVT) Received: from husky.fjoe.local (gw.nsib.ru [217.117.80.2]) by neo.samodelkin.net (Postfix) with ESMTP id 01BD917275; Thu, 3 Jan 2008 13:52:12 +0600 (NOVT) Message-ID: <477C9429.8090801@samodelkin.net> Date: Thu, 03 Jan 2008 13:52:09 +0600 From: Max Khon User-Agent: Thunderbird 2.0.0.6 (X11/20071028) MIME-Version: 1.0 To: Sepherosa Ziehau References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=0.16.4 X-Mailman-Approved-At: Thu, 03 Jan 2008 12:28:02 +0000 Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , sam@freebsd.org, net@freebsd.org, current@freebsd.org, kevlo@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 08:20:43 -0000 Hi! Sepherosa Ziehau wrote: >>> I don't whether following thingies will fix your problem: >>> [...] >> Can you provide a diff? > > http://people.freebsd.org/~sephe/rt2560_test.diff > > Hope it will have some effect. Do you have a similar patch for Ralink 2661? /fjoe From owner-freebsd-net@FreeBSD.ORG Thu Jan 3 13:10:40 2008 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 BAE4916A417 for ; Thu, 3 Jan 2008 13:10:40 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 8D4D913C457 for ; Thu, 3 Jan 2008 13:10:40 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 2202982BC9; Thu, 3 Jan 2008 08:10:40 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 03 Jan 2008 08:10:40 -0500 X-Sasl-enc: QY2PZh3nrKAD8rrAVV2dxtM6LumlMvS2uuDskgOIgg9t 1199365839 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 76647A9F7; Thu, 3 Jan 2008 08:10:39 -0500 (EST) Message-ID: <477CDECE.9010205@FreeBSD.org> Date: Thu, 03 Jan 2008 13:10:38 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Julian Elischer References: <200712170740.lBH7eYaU068543@repoman.freebsd.org> <4766D6E5.1010503@FreeBSD.org> <4766E54C.30402@elischer.org> <477BBBC7.2020800@FreeBSD.org> <477C1156.9090106@elischer.org> In-Reply-To: <477C1156.9090106@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, "ru@FreeBSD.org >> Ruslan Ermilov" Subject: Outstanding multipath related PR; Floating statics. 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, 03 Jan 2008 13:10:40 -0000 Hi there, I have been cleaning up my PRs. The last PR I have remaining in my queue is directly related to the multipath work you are doing: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71474 The problem which caused Thomas to raise the PR, is that of allowing the prefix route for 192.168.1.0/24 to float over to the other interface which *can* reach that prefix. Follow the code in in_rmx.c for in_ifadown() to understand why the problem with downed interfaces happens. Traditionally, BSD has not skipped ifnets which are marked as being down during outbound interface selection. I'm not entirely sure why we should even be looking at downed interfaces for that last part of next-hop selection in the first place. Ruslan (Cc'd) suggests there are cases where this is necessary, I can think of none. The mere fact that the first match may be used fails to take account of the ifnet referenced by rt_ifp being down would clobber correct path selection behaviour for multipath. To be sure, recursive resolution of the next-hop could solve the problem described in the PR, at the expense of introducing unnecessary complexity into the kernel FIB. However, at the end of the PR I suggest a more general approach which could be used to deal with the situation where the destination is *not* covered by interface routes -- floating statics. Both Cisco and Juniper implement floating statics in their FIBs, and they would actually allow folks who unplug their cable and expect to be able to seamlessly fail over to wireless in the most general case, by making 0.0.0.0/0 a floating static. cheers BMS From owner-freebsd-net@FreeBSD.ORG Thu Jan 3 13:16:55 2008 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 DE70616A417 for ; Thu, 3 Jan 2008 13:16:55 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id B145613C467 for ; Thu, 3 Jan 2008 13:16:55 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 4D01182EF5; Thu, 3 Jan 2008 08:16:55 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 03 Jan 2008 08:16:55 -0500 X-Sasl-enc: DvJTRO3UTRif41w6eRi+58ZROj3vQW7V+ycCV9mI9TrJ 1199366214 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id A26F327476; Thu, 3 Jan 2008 08:16:54 -0500 (EST) Message-ID: <477CE045.7000200@FreeBSD.org> Date: Thu, 03 Jan 2008 13:16:53 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Julian Elischer References: <200712170740.lBH7eYaU068543@repoman.freebsd.org> <4766D6E5.1010503@FreeBSD.org> <4766E54C.30402@elischer.org> <477BBBC7.2020800@FreeBSD.org> <477C1156.9090106@elischer.org> <477CDECE.9010205@FreeBSD.org> In-Reply-To: <477CDECE.9010205@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, "ru@FreeBSD.org >> Ruslan Ermilov" Subject: Re: Outstanding multipath related PR; Floating statics. 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, 03 Jan 2008 13:16:56 -0000 Bruce M. Simpson wrote: > > The problem which caused Thomas to raise the PR, is that of allowing > the prefix route for 192.168.1.0/24 to float over to the other > interface which *can* reach that prefix. I should also point out that the problem exists at Layer 2 and Layer 3. To be sure, if a route already exists for 192.168.1.0/24 which transits the downed interface, it will be chosen first. However if ARP entries are still in the stack, they represent the most specific match and their /32 entries will be chosen *before* any Layer 3 route, regardless of interface status. In other words, the removal of ARP entries from the routing table would solve only half of the problem that Thomas has observed. So I guess the real question is: should the lookup of the next-hop for a "connected" route, that is, the network prefix route associated with an interface, be allowed to "float" to the next interface which is UP? I think it should. Interface routes are NOT STATIC routes. I'm in favour of retaining the existing meaning of STATIC routes. But I also think we should allow the IFP resolution for STATIC routes to "float" if they are configured as FLOATING STATICs as this is what most folk really want the forwarding code to do. regards BMS From owner-freebsd-net@FreeBSD.ORG Thu Jan 3 13:34:49 2008 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 5079916A418; Thu, 3 Jan 2008 13:34:49 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 119B413C44B; Thu, 3 Jan 2008 13:34:49 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 92B818296B; Thu, 3 Jan 2008 08:34:48 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 03 Jan 2008 08:34:48 -0500 X-Sasl-enc: HqL3WxBJaqol0Umex0Nr6hBA7145Jo0dMFHsL7Ox5GKt 1199367287 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 5C62F27497; Thu, 3 Jan 2008 08:34:47 -0500 (EST) Message-ID: <477CE476.9000205@FreeBSD.org> Date: Thu, 03 Jan 2008 13:34:46 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Andre Oppermann References: <43B45EEF.6060800@x-trader.de> <43B47CB5.3C0F1632@freebsd.org> <477C1434.80106@freebsd.org> <477C1776.2080002@FreeBSD.org> <477C25E2.4080303@freebsd.org> In-Reply-To: <477C25E2.4080303@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Tiffany Snyder , Julian Elischer Subject: Re: Routing SMP benefit 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, 03 Jan 2008 13:34:49 -0000 Andre Oppermann wrote: > Haven't looked at the multicast code so I can't comment. The other > stuff is just talk so far. No work in progress, at least from my side. Insofaras rmlocks and cache line size vs rtentry size applies to multicast: I know there are implementations out there which use the unicast BSD routing code to do multicast. This is preferable as the MROUTING implementation in the main tree has a 32 vif limitation. Moving this into the main radix trie code allows us to overcome these limitations. Recall that a multipath FIB holds multiple next-hops for each route. Multicast routes need the same, but they also need to send traffic to all of the next-hops. This is basically what the MROUTING code does, but it does so completely separately from the unicast forwarding code. The reasons for this are mostly historical -- folks wanted to develop it separately from unicast IPv4. For IETF MANET, ie tactical mobile IP networks, we need to be able to address multicast next-hops by their unicast address -- most of the time we can't reliably use link layer multicast or even IGMP to reach all subscribers, or use PIM shared trees, so flooding is necessary -- as well as being able to disable the existing RPF checks on inbound traffic from MANET interfaces. In situations like this, 32 next-hop I'm aware this is only marginally related to the DFZ/tier-1 router scenario, but, it's something I want FreeBSD to support as it allows IP networks to be deployed in novel situations i.e. where no existing infrastructure exists, and centralized/hierarchical network infrastructure isn't suitable (think International Rescue). So it's something to think about for folks doing multipath work -- the same performance constraints which affect struct rtentry *now* for SMP and multipath work will potentially affect multicast forwarding in future. regards BMS From owner-freebsd-net@FreeBSD.ORG Thu Jan 3 14:37:26 2008 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 DDEF616A417; Thu, 3 Jan 2008 14:37:26 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 93A9413C45B; Thu, 3 Jan 2008 14:37:26 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 27363207E; Thu, 3 Jan 2008 15:37:18 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.1/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 8DF1E2049; Thu, 3 Jan 2008 15:37:17 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 70B99844C3; Thu, 3 Jan 2008 15:37:17 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Sepherosa Ziehau" References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> <86abnovy4k.fsf@ds4.des.no> Date: Thu, 03 Jan 2008 15:37:17 +0100 In-Reply-To: <86abnovy4k.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?= =?utf-8?Q?rav=22's?= message of "Wed\, 02 Jan 2008 20\:14\:03 +0100") Message-ID: <86odc3dlgi.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 14:37:27 -0000 Dag-Erling Sm=C3=B8rgrav writes: > "Sepherosa Ziehau" writes: > > http://people.freebsd.org/~sephe/rt2560_test.diff > I built a new kernel with the patch applied, and it seems to help, > though it's a bit early to say for sure. Didn't help. A large rsync over ssh stalls the connection within minutes. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-net@FreeBSD.ORG Thu Jan 3 15:12:24 2008 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 B39F316A418 for ; Thu, 3 Jan 2008 15:12:24 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from relay1.tpu.ru (relay1.tpu.ru [213.183.112.102]) by mx1.freebsd.org (Postfix) with ESMTP id 0974C13C4E8 for ; Thu, 3 Jan 2008 15:12:23 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from localhost (localhost.localdomain [127.0.0.1]) by relay1.tpu.ru (Postfix) with ESMTP id 8583610459F; Thu, 3 Jan 2008 21:12:20 +0600 (NOVT) X-Virus-Scanned: amavisd-new at tpu.ru Received: from relay1.tpu.ru ([127.0.0.1]) by localhost (relay1.tpu.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxvKPxzaM4J5; Thu, 3 Jan 2008 21:12:17 +0600 (NOVT) Received: from mail.main.tpu.ru (mail.main.tpu.ru [10.0.0.3]) by relay1.tpu.ru (Postfix) with ESMTP id 507381044D0; Thu, 3 Jan 2008 21:12:17 +0600 (NOVT) Received: from mail.tpu.ru ([213.183.112.105]) by mail.main.tpu.ru with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Jan 2008 21:12:17 +0600 Received: from nuclight.avtf.net ([78.140.2.250]) by mail.tpu.ru over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Jan 2008 21:12:17 +0600 Date: Thu, 03 Jan 2008 21:12:12 +0600 To: "Julian Elischer" , "Ivo Vachkov" References: <4772F123.5030303@elischer.org> <477416CC.4090906@elischer.org> From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <477416CC.4090906@elischer.org> User-Agent: Opera M2/7.54 (Win32, build 3865) X-OriginalArrivalTime: 03 Jan 2008 15:12:17.0135 (UTC) FILETIME=[072A37F0:01C84E1B] Cc: arch@freebsd.org, FreeBSD Net , Robert Watson , Qing Li Subject: Re: resend: multiple routing table roadmap (format fix) 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, 03 Jan 2008 15:12:24 -0000 28.12.07 @ 03:19 Julian Elischer wrote: > By the way, I might add that in the 6.x compat. version I may end up > limiting the feature to 8 tables. This is because I need to store some > stuff in an efficient way in the mbuf, and in a compatible manner this > is easiest done by stealing the top 4 bits in the mbuf dlags word > and defining them as: > > #define M_HAVEFIB 0x10000000 > #define M_FIBMASK 0x07 > #define M_FIBNUM 0xe0000000 > #define M_FIBSHIFT 29 > #define m_getfib(_m, _default) ((m->m_flags & M_HAVE_FIBNUM) ? > ((m->m_flags >> M_FIBSHIFT) & M_FIBMASK) : _default) > #M_SETFIB(_m, _fib) do { \ > _m->m_flags &= ~M_FIBNUM; \ > _m->m_flags |= (M_HAVEFIB|((_fib & M_FIBMASK) << M_FIBSHIFT));\ > } while (0) > > This then becomes very easy to change to use a tag or > whatever is needed in later versions , and the number can > be expanded past 8 predefined FIBs at that time.. If you want it to be a tag, why spent bits in m_flags and not just do it as a tag at once? Or it is supposed to completely throw away 6.x (possibly 7.x too) implementation in favor of right thing in 8.0 ? >>> This brings us as to how the correct FIB is selected for an outgoing >>> IPV4 packet. >>> >>> Packets fall into one of a number of classes. >>> 1/ locally generated packets, coming from a socket/PCB. >>> Such packets select a FIB from a number associated with the >>> socket/PCB. This in turn is inherited from the process, >>> but can be changed by a socket option. The process in turn >>> inherits it on fork. I have written a utility call setfib >>> that acts a bit like nice.. >>> >>> setfib -n 3 ping target.example.com # will use fib 3 for ping. Pretty cool! >>> 2/ packets received on an interface for forwarding. >>> By default these packets would use table 0, >>> (or possibly a number settable in a sysctl(not yet)). >>> but prior to routing the firewall can inspect them (see below). >>> >>> 3/ packets inspected by a packet classifier, which can arbitrarily >>> associate a fib with it on a packet by packet basis. >>> A fib assigned to a packet by a packet classifier >>> (such as ipfw) would over-ride a fib associated by >>> a more default source. (such as cases 1 or 2). Sounds good. I like idea to do routing decisions in firewall, to not double kernel code and userspace utilities, like in Linux' iproute2 (which, however, still have a few parameters and relies on firewall marks for others). However, there are some cases, I think, where it could be done outisde firewall. For example, make an ifconfig option to use a specific FIB as a default for all packets outgoing from this interface's address. But here arises another related question - Linux allows to select a specific src IP based on a routing table entry - destination address (thoughts about pf reply-to/route-ro, huh). In relation to this I can remember multipath routing (different metrics?), addresses from one subnet on different ifaces (mask wider /32) and so on. Also it is interesting, how multiple FIBs would interact with host-wide events, such as ICMP redirects (which table should be updated?), storing of TCP stack metrics (MTU, etc.) and hostcache, and so on. How these and above will be solved?.. per ifconfig (>1 host per subnet)/icmp redirects/src to prefer, multipath/metrics, tcp stack parameters interaction, iproute2 >>> Routing messages would be associated with their >>> process, and thus select one FIB or another. This is not clear. How should the 'route' command work with different FIBs, if they are supposed by admin to be used for forwarding, and not the straight per-process? I think a setfib option is more consistent than running route under setfib command. Also, routing sockets and routing daemons - should they work with only one table?.. >>> I have not yet added the changes to ipfw. Action modifier, like 'ipfw add count setfib 3 ip from any to any' ? There were thoughts (I heard,t as a hack before multiple FIBs) about making an additional, say, 'nexthop' ipfw action, which acts like fwd, but does not accept packet, allowing to continue it through firewall ruleset - thus making it more comfortable to separate routing (imagine 'nexthop tablearg') and filtering. There are questions with both fwd and new supposed option: will fwd still survive? Will it change the output interface, like as complete rerouting before calling pfil(9) hooks, so that *oif will be changed to be mathed iin rules below? pf route-to/reply-to is hanging around... >>> pf has some similar changes already but they seem to rely on >>> the various FIBs having symbolic names. Which I do not plan to support >>> in the first version of these changes. I think this is what pf team should care about, not we, as it lives in ../contrib. Though they can use something like sysctl with symbolic-name-to-system-FIB-number translator or such. >>> Interaction with the ARP layer/ LL layer would need to be >>> revisited as well. Qing Li has been working on this already. Oh yes, L2 interaction is interesting. How it should work in case of planned separation of routing and ARP tables?.. -- WBR, Vadim Goncharov From owner-freebsd-net@FreeBSD.ORG Thu Jan 3 18:52:23 2008 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 021C116A468 for ; Thu, 3 Jan 2008 18:52:23 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outY.internet-mail-service.net (outY.internet-mail-service.net [216.240.47.248]) by mx1.freebsd.org (Postfix) with ESMTP id CDE7213C448 for ; Thu, 3 Jan 2008 18:52:22 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Thu, 03 Jan 2008 10:52:21 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id B0748126DE4; Thu, 3 Jan 2008 10:52:20 -0800 (PST) Message-ID: <477D2EF3.2060909@elischer.org> Date: Thu, 03 Jan 2008 10:52:35 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Vadim Goncharov References: <4772F123.5030303@elischer.org> <477416CC.4090906@elischer.org> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Ivo Vachkov , Robert Watson , Qing Li , FreeBSD Net Subject: Re: resend: multiple routing table roadmap (format fix) 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, 03 Jan 2008 18:52:23 -0000 Vadim Goncharov wrote: > 28.12.07 @ 03:19 Julian Elischer wrote: > >> By the way, I might add that in the 6.x compat. version I may end up >> limiting the feature to 8 tables. This is because I need to store some >> stuff in an efficient way in the mbuf, and in a compatible manner this >> is easiest done by stealing the top 4 bits in the mbuf dlags word >> and defining them as: >> >> #define M_HAVEFIB 0x10000000 >> #define M_FIBMASK 0x07 >> #define M_FIBNUM 0xe0000000 >> #define M_FIBSHIFT 29 >> #define m_getfib(_m, _default) ((m->m_flags & M_HAVE_FIBNUM) ? >> ((m->m_flags >> M_FIBSHIFT) & M_FIBMASK) : _default) >> #M_SETFIB(_m, _fib) do { \ >> _m->m_flags &= ~M_FIBNUM; \ >> _m->m_flags |= (M_HAVEFIB|((_fib & M_FIBMASK) << M_FIBSHIFT));\ >> } while (0) >> >> This then becomes very easy to change to use a tag or >> whatever is needed in later versions , and the number can >> be expanded past 8 predefined FIBs at that time.. > > If you want it to be a tag, why spent bits in m_flags and not just do it > as a tag at once? Or it is supposed to completely throw away 6.x > (possibly 7.x too) implementation in favor of right thing in 8.0 ? basically yes.. I'm looking at just doing tags to start with, but haven't done it yet.. I'm looking for a good bit of tag code to copy :-) > >>>> This brings us as to how the correct FIB is selected for an outgoing >>>> IPV4 packet. >>>> >>>> Packets fall into one of a number of classes. >>>> 1/ locally generated packets, coming from a socket/PCB. >>>> Such packets select a FIB from a number associated with the >>>> socket/PCB. This in turn is inherited from the process, >>>> but can be changed by a socket option. The process in turn >>>> inherits it on fork. I have written a utility call setfib >>>> that acts a bit like nice.. >>>> >>>> setfib -n 3 ping target.example.com # will use fib 3 for ping. > > Pretty cool! or, (and I've done this) setfib 3 /bin/sh now by default everythign you do uses table 3. or even setfib 3 jail {blah} and all the procs in the jail use table 3. You also need to do setfib 3 jexec xxx for extra processes you add to the jail afterwards. > >>>> 2/ packets received on an interface for forwarding. >>>> By default these packets would use table 0, >>>> (or possibly a number settable in a sysctl(not yet)). >>>> but prior to routing the firewall can inspect them (see below). >>>> >>>> 3/ packets inspected by a packet classifier, which can arbitrarily >>>> associate a fib with it on a packet by packet basis. >>>> A fib assigned to a packet by a packet classifier >>>> (such as ipfw) would over-ride a fib associated by >>>> a more default source. (such as cases 1 or 2). > > Sounds good. I like idea to do routing decisions in firewall, to not > double kernel code and userspace utilities, like in Linux' iproute2 > (which, however, still have a few parameters and relies on firewall > marks for others). However, there are some cases, I think, where it > could be done outisde firewall. For example, make an ifconfig option to > use a specific FIB as a default for all packets outgoing from this > interface's address. But here arises another related question - Linux > allows to select a specific src IP based on a routing table entry - > destination address (thoughts about pf reply-to/route-ro, huh). that is default here too if I understand what you are talking about. teh src address is selected from the routing table's exit interface. In the code I'm showing in perforce, that address would depend on which table your process was associated with. (or just the socket if you have used the socket option on it before doing the bind/connect) > In > relation to this I can remember multipath routing (different metrics?), > addresses from one subnet on different ifaces (mask wider /32) and so on. > Also it is interesting, how multiple FIBs would interact with host-wide > events, such as ICMP redirects (which table should be updated?), storing > of TCP stack metrics (MTU, etc.) and hostcache, and so on. How these and > above will be solved?.. > I'm not really too knowledgeable about multicast.. > per ifconfig (>1 host per subnet)/icmp redirects/src to prefer, > multipath/metrics, tcp stack parameters interaction, iproute2 I'm not trying to solve problems that need vimage to solve them.. > >>>> Routing messages would be associated with their >>>> process, and thus select one FIB or another. > > This is not clear. How should the 'route' command work with different > FIBs, if they are supposed by admin to be used for forwarding, and not > the straight per-process? I think a setfib option is more consistent > than running route under setfib command. Also, routing sockets and > routing daemons - should they work with only one table?.. if you do setfib 3 route get 1.1.1.1 you may get a different result from setfib 2 route get 1.1.1.1 I will add a fibnum argument to route itself as well but it's not needed immediately as long as I have the setfib command. > >>>> I have not yet added the changes to ipfw. > > Action modifier, like 'ipfw add count setfib 3 ip from any to any' ? > There were thoughts (I heard,t as a hack before multiple FIBs) about > making an additional, say, 'nexthop' ipfw action, which acts like fwd, > but does not accept packet, allowing to continue it through firewall > ruleset - thus making it more comfortable to separate routing (imagine > 'nexthop tablearg') and filtering. There are questions with both fwd and > new supposed option: will fwd still survive? Will it change the output > interface, like as complete rerouting before calling pfil(9) hooks, so > that *oif will be changed to be mathed iin rules below? pf > route-to/reply-to is hanging around... The 'nexthop' cal you suggest is problematic because it needs to return information immediately. which is why it is terminal. As for the setfib ipfw action, I have now done this in p4. ipfw add 200 setfib 3 ip from any to any in receive em0 now works. This lessens the need for associating a fib with an interface as the firewall can do that too.. the setfib rule is not terminal. (hmm need to check I did that right.) you can also do ipfw add 200 skipto 300 ip from any to any hasfib # to select on a packet that has a fib associated with it already. ipfw add 200 skipto 300 ip from any to any fib 4 # to slelect packets that are associated with fib 4 ipfw add 200 clrfib ip from any to any # to remove a fib association from the packet. > >>>> pf has some similar changes already but they seem to rely on >>>> the various FIBs having symbolic names. Which I do not plan to support >>>> in the first version of these changes. > > I think this is what pf team should care about, not we, as it lives in > ../contrib. Though they can use something like sysctl with > symbolic-name-to-system-FIB-number translator or such. > >>>> Interaction with the ARP layer/ LL layer would need to be >>>> revisited as well. Qing Li has been working on this already. > > Oh yes, L2 interaction is interesting. How it should work in case of > planned separation of routing and ARP tables?.. > From owner-freebsd-net@FreeBSD.ORG Fri Jan 4 02:24:03 2008 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 AAA0C16A419 for ; Fri, 4 Jan 2008 02:24:03 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.189]) by mx1.freebsd.org (Postfix) with ESMTP id 3AEA313C45D for ; Fri, 4 Jan 2008 02:24:03 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so6365775rvb.43 for ; Thu, 03 Jan 2008 18:24:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=yM6JjChj0ISeitgb+6UqXjZKJ1FbxW+KalJl3zCz4iI=; b=wA8f4JNQDx1vpM6NBVc0DVmMZ+y6aLTfNGXQ0f9ko8be5bcihaCsPME6HcdNOWYvxoIpAcH48Dus/wJDNwWt7ytyffRtsf0vcz7fqJN+ghkC858URbBfFi/TSisG2zSXEXw8ibMr0fRxdEbefQzlMqaSzduOV8ZIr/Dp8OgnVzI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=yBuSUQWvglqCxVGUt2AXVE0RslB7yE1XAnIm0McSXy6p1sG4M5rZj3eL6HTmZJKsLnJbIMvpKYM8S2PPAJFQ0xwEmlsaNGfS9WMnLDWKHGU2F3GsnrPygWn8WJa5l6viz+UJ5NGfuArTW0SbdGOPedLy1pzdY4sITy7BrvTiJx4= Received: by 10.142.229.4 with SMTP id b4mr3717456wfh.125.1199413442890; Thu, 03 Jan 2008 18:24:02 -0800 (PST) Received: by 10.142.162.20 with HTTP; Thu, 3 Jan 2008 18:24:02 -0800 (PST) Message-ID: Date: Fri, 4 Jan 2008 10:24:02 +0800 From: "Sepherosa Ziehau" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86odc3dlgi.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> <86abnovy4k.fsf@ds4.des.no> <86odc3dlgi.fsf@ds4.des.no> Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 02:24:03 -0000 On Jan 3, 2008 10:37 PM, Dag-Erling Sm=F8rgrav wrote: > Dag-Erling Sm=F8rgrav writes: > > "Sepherosa Ziehau" writes: > > > http://people.freebsd.org/~sephe/rt2560_test.diff > > I built a new kernel with the patch applied, and it seems to help, > > though it's a bit early to say for sure. > > Didn't help. A large rsync over ssh stalls the connection within > minutes. Are you also using freebsd as STA too? If yes, would you have time to gather following information on the STA side before after and during the rsyncing: 1) wlandebug -i sta_iface +input 2) tcpdump -ni sta_iface -y ieee802_11 -w dump.bin Best Regards, sephe --=20 Live Free or Die From owner-freebsd-net@FreeBSD.ORG Fri Jan 4 04:32:59 2008 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 B62E716A41B for ; Fri, 4 Jan 2008 04:32:59 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by mx1.freebsd.org (Postfix) with ESMTP id 7E30B13C4F5 for ; Fri, 4 Jan 2008 04:32:59 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so6404448rvb.43 for ; Thu, 03 Jan 2008 20:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:organization:x-operation-sytem:from; bh=rkLLLB0lY92dNrN4BV1vyZdNHWMyPX+1+199LPU2kJc=; b=QR675HN2OyKFpA85xGXVcMAn7oca2ogbySRsEzpQFp2QzgPKkQXBOkgKCJ0t8bl5Geda+AjhEiIOILqOLz8UUaEOJKgoD23xJv0VAsyjPGQC6aNQh2Vx6aUCNdlpwDL25xwBzGwJ4Sg9hoglByKcf1NfGwX0Gii/YGaTcd6/Dbs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:organization:x-operation-sytem:from; b=kXxqFGFDtf/8nMfIgAJgx+dQsWAUG8QY4so2CMIB2XVVou9OLymkQECE8exBrN6xUoGVrmY+AuuxREMqcQlrogDt6egpiadCwSFTOMFVeIp6pVn24mwq83dd46sJxH4nP4U/leSan4Dtb4kGOau+mT1ObRL3GVD3/Zcexr1HBdg= Received: by 10.141.2.19 with SMTP id e19mr8562328rvi.221.1199421179047; Thu, 03 Jan 2008 20:32:59 -0800 (PST) Received: from freebsd.weongyo.org ( [211.53.35.67]) by mx.google.com with ESMTPS id g6sm3276196rvb.25.2008.01.03.20.32.55 (version=SSLv3 cipher=OTHER); Thu, 03 Jan 2008 20:32:58 -0800 (PST) Received: by freebsd.weongyo.org (sSMTP sendmail emulation); Fri, 4 Jan 2008 13:32:44 +0900 Date: Fri, 4 Jan 2008 13:32:44 +0900 To: Sepherosa Ziehau Message-ID: <20080104043244.GA9641@freebsd.weongyo.org> Mail-Followup-To: Sepherosa Ziehau , Dag-Erling =?UTF8?Q?Sm=F8rgrav?= , kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org References: <86ir2hznnd.fsf@ds4.des.no> <20080102023831.GA53242@freebsd.weongyo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD From: Weongyo Jeong Cc: Dag-Erling =?UTF8?Q?Sm=F8rgrav?= , sam@freebsd.org, net@freebsd.org, current@freebsd.org, kevlo@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 04:32:59 -0000 On Wed, Jan 02, 2008 at 09:28:30PM +0800, Sepherosa Ziehau wrote: > On Jan 2, 2008 10:38 AM, Weongyo Jeong wrote: > > > > > Even with these in place in dfly, I still have strange TX performance > > > regression in sta mode (drop from 20Mb/s to 3Mb/s under very well > > > condition) on certain hardwares after 20sec~30sec TCP_STREAM netperf > > > testing; didn't have enough time to dig, however, all of the tested > > > hardwares stayed connected during testing (I usually run netperf > > > stream test for 12 hours or more). > > > > I also saw some regression in TX performance during porting malo(4). > > Have you tried to turn bgscan off completely? My problem seems to be > hardware (I suspect rf) related. The TX performance regression does > not happen with UDP stream which only uses 802.11 ack, i.e. hardware > seems to have touble to switch between data RX and data TX at high > freq. Oops. It seems this problem is a different one because I always encounter system crashes (I can't enter DDB, no keyboard works and no messages on screen) within a hour with HEAD when I tested netperf(1) TX tests using malo(4) that the tested driver was never crashed before during testing netperf(1) tests for several hours. Before 1~2 months ago, it wasn't happen. It looks weird and I'm also going to dig it. > > Problems were fixed after removing following lines in *_start: > > > > /* > > * Cancel any background scan. > > */ > > if (ic->ic_flags & IEEE80211_F_SCAN) > > ieee80211_cancel_scan(ic); > > > > and (optionally) > > > > if (m->m_flags & M_TXCB) > > ... > > ieee80211_process_callback(ni, m, 0); /* XXX status? > > ... > > I don't think you can remove TXCB processing in drivers :) Yes, indeed. :-) regards, Weongyo Jeong From owner-freebsd-net@FreeBSD.ORG Fri Jan 4 05:51:34 2008 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 196CC16A419; Fri, 4 Jan 2008 05:51:34 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from neo.samodelkin.net (samodelkin.net [195.62.0.66]) by mx1.freebsd.org (Postfix) with ESMTP id AA15013C465; Fri, 4 Jan 2008 05:51:33 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: by neo.samodelkin.net (Postfix, from userid 10117) id 4CD7817305; Fri, 4 Jan 2008 11:51:31 +0600 (NOVT) Received: from husky.fjoe.local (gw.nsib.ru [217.117.80.2]) by neo.samodelkin.net (Postfix) with ESMTP id E42E8172F1; Fri, 4 Jan 2008 11:51:30 +0600 (NOVT) Message-ID: <477DC95D.9010701@samodelkin.net> Date: Fri, 04 Jan 2008 11:51:25 +0600 From: Max Khon User-Agent: Thunderbird 2.0.0.6 (X11/20071028) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> <86abnovy4k.fsf@ds4.des.no> <86odc3dlgi.fsf@ds4.des.no> In-Reply-To: <86odc3dlgi.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=0.16.4 Cc: Sepherosa Ziehau , kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 05:51:34 -0000 Hi! Dag-Erling SmÞrgrav wrote: >>> http://people.freebsd.org/~sephe/rt2560_test.diff >> I built a new kernel with the patch applied, and it seems to help, >> though it's a bit early to say for sure. > > Didn't help. A large rsync over ssh stalls the connection within > minutes. Have you tried to turn off bgscan? /fjoe From owner-freebsd-net@FreeBSD.ORG Fri Jan 4 08:51:26 2008 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 5657F16A417; Fri, 4 Jan 2008 08:51:26 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 0DE0213C44B; Fri, 4 Jan 2008 08:51:26 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id AF30F20BB; Fri, 4 Jan 2008 09:51:18 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.1/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 9B2A32099; Fri, 4 Jan 2008 09:51:18 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 80866844CD; Fri, 4 Jan 2008 09:51:18 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Sepherosa Ziehau" References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> <86abnovy4k.fsf@ds4.des.no> <86odc3dlgi.fsf@ds4.des.no> Date: Fri, 04 Jan 2008 09:51:18 +0100 In-Reply-To: (Sepherosa Ziehau's message of "Fri\, 4 Jan 2008 10\:24\:02 +0800") Message-ID: <86lk76c6t5.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 08:51:26 -0000 "Sepherosa Ziehau" writes: > Are you also using freebsd as STA too? If yes, would you have time to > gather following information on the STA side before after and during > the rsyncing: > 1) wlandebug -i sta_iface +input > 2) tcpdump -ni sta_iface -y ieee802_11 -w dump.bin I'll have to pull out an old laptop to do that, my current one runs Ubuntu. Hopefully, I'll have the results for you later today. I imagine you want to see the output from wlandebug both when the AP is working and when it is stuck? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-net@FreeBSD.ORG Fri Jan 4 08:52:37 2008 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 981C016A41B; Fri, 4 Jan 2008 08:52:37 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 4EA2013C467; Fri, 4 Jan 2008 08:52:37 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 3228320BB; Fri, 4 Jan 2008 09:52:29 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 1F3482099; Fri, 4 Jan 2008 09:52:28 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id CC56D844CD; Fri, 4 Jan 2008 09:52:28 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Max Khon References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> <86abnovy4k.fsf@ds4.des.no> <86odc3dlgi.fsf@ds4.des.no> <477DC95D.9010701@samodelkin.net> Date: Fri, 04 Jan 2008 09:52:28 +0100 In-Reply-To: <477DC95D.9010701@samodelkin.net> (Max Khon's message of "Fri\, 04 Jan 2008 11\:51\:25 +0600") Message-ID: <86hchuc6r7.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Sepherosa Ziehau , kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 08:52:37 -0000 Max Khon writes: > Have you tried to turn off bgscan? bgscan is obviously not running since the broken ral is in the AP. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-net@FreeBSD.ORG Fri Jan 4 14:11:58 2008 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 D7E6216A46D for ; Fri, 4 Jan 2008 14:11:58 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.235]) by mx1.freebsd.org (Postfix) with ESMTP id 91C3E13C4CC for ; Fri, 4 Jan 2008 14:11:53 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so1266335nzf.13 for ; Fri, 04 Jan 2008 06:11:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Auo6u/ahvPWQveev1o9Jl5ADa20pxZnwSALscTcreMs=; b=jOo1z1OurCs/LeK7jjBz0UNmO7hMESoALMNFbDNgGVMbC/3A9RxkRMWR2NSL5dPdqBE3XLbi6o9i68XreH1JqjGOdd6yU6p5fni82gjaPRks7Eh8O3fxJWgC+BSFb1QxE7bXFcBc6SsXzaq2Kn15JwIZT0uPUgTZLbNwAaiCtCY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TVlQR1uT5u9/CpHCeigI4LpfkoS/VOnFiz6cE8nclFh7DgLrLbty9886X4zO4cLExw51aHPp0Ts2yHDPHv2fioGQSmH/t7la+R0GSpY62b6RsNc2zt7ASadUT9sTaIYmYy5Qo7hma1vQi2EPiwM5HXHYJJqM3poyiibQJJ2X0/M= Received: by 10.142.212.19 with SMTP id k19mr5106641wfg.200.1199455911649; Fri, 04 Jan 2008 06:11:51 -0800 (PST) Received: by 10.142.162.20 with HTTP; Fri, 4 Jan 2008 06:11:51 -0800 (PST) Message-ID: Date: Fri, 4 Jan 2008 22:11:51 +0800 From: "Sepherosa Ziehau" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86lk76c6t5.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> <86abnovy4k.fsf@ds4.des.no> <86odc3dlgi.fsf@ds4.des.no> <86lk76c6t5.fsf@ds4.des.no> Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 14:11:58 -0000 On Jan 4, 2008 4:51 PM, Dag-Erling Sm=F8rgrav wrote: > "Sepherosa Ziehau" writes: > > Are you also using freebsd as STA too? If yes, would you have time to > > gather following information on the STA side before after and during > > the rsyncing: > > 1) wlandebug -i sta_iface +input > > 2) tcpdump -ni sta_iface -y ieee802_11 -w dump.bin > > I'll have to pull out an old laptop to do that, my current one runs > Ubuntu. Hopefully, I'll have the results for you later today. I > imagine you want to see the output from wlandebug both when the AP is > working and when it is stuck? Yes. I just did some air dump of ral's beacon and data frame A sample ral(4) broadcast beacon frame: 21:26:26.662250 Beacon (sephe-hostap) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] ESS CH: 6 0x0000: 8000 0000 ffff ffff ffff 0015 f2d7 420c 0x0010: 0015 f2d7 420c 0000 e053 4a10 0000 0000 0x0020: 6400 2104 000c 7365 7068 652d 686f 7374 0x0030: 6170 0108 8284 8b96 0c12 1824 0301 0605 0x0040: 0400 0101 002a 0100 3204 3048 606c The seq is 0!! Two sample ral(4) data frames (ICMP echo resps) 21:26:27.810209 IP 192.168.5.2 > 192.168.5.1: ICMP echo request, id 61969, seq 1, length 64 0x0000: 0801 2c00 0015 f2d7 420c 0014 787a 5990 0x0010: 0015 f2d7 420c f0b1 aaaa 0300 0000 0800 0x0020: 4500 0054 0e75 0000 4001 e0e0 c0a8 0502 0x0030: c0a8 0501 0800 42b2 f211 0001 477e 3403 0x0040: 000c 5caa 0809 0a0b 0c0d 0e0f 1011 1213 0x0050: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 21:26:28.820190 IP 192.168.5.2 > 192.168.5.1: ICMP echo request, id 61969, seq 2, length 64 0x0000: 0801 2c00 0015 f2d7 420c 0014 787a 5990 0x0010: 0015 f2d7 420c 00b2 aaaa 0300 0000 0800 0x0020: 4500 0054 f517 0000 4001 fa3d c0a8 0502 0x0030: c0a8 0501 0800 1bb1 f211 0002 477e 3404 0x0040: 000c 83a9 0809 0a0b 0c0d 0e0f 1011 1213 0x0050: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 802.11 stack does the right thing here, seq is incremented between two fram= es. This actually brings up two things: 1) I think should ignore seq in multicast frames; this is permitted in 802.11 standard. In dfly I did that, since one of our users encountered a broken commercial AP which is not 802.11e but use different beacon se --=20 Live Free or Die From owner-freebsd-net@FreeBSD.ORG Fri Jan 4 14:20:50 2008 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 529F416A41B for ; Fri, 4 Jan 2008 14:20:50 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.237]) by mx1.freebsd.org (Postfix) with ESMTP id 0236F13C4E5 for ; Fri, 4 Jan 2008 14:20:49 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so1268943nzf.13 for ; Fri, 04 Jan 2008 06:20:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=XUfzhWiPvibjl+4pAvSRIATeeuY/MnHnU5BJGFvoC3M=; b=a295olCP04njz6P9VIj2XP+1jbzu+rxJ23TWLoUDdiQHP1nRC5jherzz3QFq/Lg71wkEdkeI9shu8Q9exUuYUr4AvCBjWOpSiwJbgbPTR4CS2xIr73UmQAc3fTvEFIGE16aXGJPb0aLd6CjJV+jwzf3S9swFUXFAQuroVvCxq2Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lXQE/E+TI1OtONwhvPsjyV9h5ioYteQj4h6qOEP1i0bB4qAVssIdRL3kzcMpauWRrqjSIyZEpwnCRbO2PZrJPFb9rH7hbNIpqc+n8pOBQ3Oubi601KOlnDX3+sWWePh5Iu1j8Eu5Qr7tGmSGeQfbhQ0gFeYWwExkc7jjQWezjvE= Received: by 10.143.173.2 with SMTP id a2mr1241885wfp.168.1199456448741; Fri, 04 Jan 2008 06:20:48 -0800 (PST) Received: by 10.142.162.20 with HTTP; Fri, 4 Jan 2008 06:20:48 -0800 (PST) Message-ID: Date: Fri, 4 Jan 2008 22:20:48 +0800 From: "Sepherosa Ziehau" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86lk76c6t5.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> <86abnovy4k.fsf@ds4.des.no> <86odc3dlgi.fsf@ds4.des.no> <86lk76c6t5.fsf@ds4.des.no> Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 14:20:50 -0000 On Jan 4, 2008 4:51 PM, Dag-Erling Sm=F8rgrav wrote: > "Sepherosa Ziehau" writes: > > Are you also using freebsd as STA too? If yes, would you have time to > > gather following information on the STA side before after and during > > the rsyncing: > > 1) wlandebug -i sta_iface +input > > 2) tcpdump -ni sta_iface -y ieee802_11 -w dump.bin > > I'll have to pull out an old laptop to do that, my current one runs > Ubuntu. Hopefully, I'll have the results for you later today. I > imagine you want to see the output from wlandebug both when the AP is > working and when it is stuck? > > DES > -- > > Dag-Erling Sm=F8rgrav - des@des.no > Grr, keyboard mis-fire :P Yes. I just did some air dump of ral's beacon and data frame A sample ral(4) broadcast beacon frame: 21:26:26.662250 Beacon (sephe-hostap) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] ESS CH: 6 0x0000: 8000 0000 ffff ffff ffff 0015 f2d7 420c 0x0010: 0015 f2d7 420c 0000 e053 4a10 0000 0000 0x0020: 6400 2104 000c 7365 7068 652d 686f 7374 0x0030: 6170 0108 8284 8b96 0c12 1824 0301 0605 0x0040: 0400 0101 002a 0100 3204 3048 606c The seq is 0!! Two sample ral(4) data frames (ICMP echo resps) 21:26:27.810209 IP 192.168.5.2 > 192.168.5.1: ICMP echo request, id 61969, seq 1, length 64 0x0000: 0801 2c00 0015 f2d7 420c 0014 787a 5990 0x0010: 0015 f2d7 420c f0b1 aaaa 0300 0000 0800 0x0020: 4500 0054 0e75 0000 4001 e0e0 c0a8 0502 0x0030: c0a8 0501 0800 42b2 f211 0001 477e 3403 0x0040: 000c 5caa 0809 0a0b 0c0d 0e0f 1011 1213 0x0050: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 21:26:28.820190 IP 192.168.5.2 > 192.168.5.1: ICMP echo request, id 61969, seq 2, length 64 0x0000: 0801 2c00 0015 f2d7 420c 0014 787a 5990 0x0010: 0015 f2d7 420c 00b2 aaaa 0300 0000 0800 0x0020: 4500 0054 f517 0000 4001 fa3d c0a8 0502 0x0030: c0a8 0501 0800 1bb1 f211 0002 477e 3404 0x0040: 000c 83a9 0809 0a0b 0c0d 0e0f 1011 1213 0x0050: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 802.11 stack does the right thing here, seq is incremented between two fram= es. This actually brings up two things: 1) I think we should ignore seq in multicast frames; this is permitted in 802.11 standard. In dfly I did that, since one of our users encountered a broken commercial AP which is not 802.11e but uses different seq for data and beacon. 2) TX sequence. I think standards only mention QSTA/nQSTA, but not AP. Currently our AP uses per node TX seq, which means beacon's seq is difficult to choose, at least for 2560 based ral(4), whose beacons' seq need to be set by software. I saw Linksys AP uses one seq for all of the frames it sends. Sam, what's you opinion on this? I think if STA counts ral(4)'s beacon seq, as what we do currently, beacon missing will quickly happen since beacons will be discarded after first several data frames. Best Regards, sephe --=20 Live Free or Die From owner-freebsd-net@FreeBSD.ORG Fri Jan 4 20:00:57 2008 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 F1BDD16A421; Fri, 4 Jan 2008 20:00:57 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from postfix2-g20.free.fr (postfix2-g20.free.fr [212.27.60.43]) by mx1.freebsd.org (Postfix) with ESMTP id 8195713C45B; Fri, 4 Jan 2008 20:00:57 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix2-g20.free.fr (Postfix) with ESMTP id CB2B521CB67C; Fri, 4 Jan 2008 18:25:41 +0100 (CET) Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id DBFEA3F6190; Fri, 4 Jan 2008 20:26:22 +0100 (CET) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 8CE3F3F61A3; Fri, 4 Jan 2008 20:26:22 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id E31F89B497; Fri, 4 Jan 2008 19:23:04 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id CE544405B; Fri, 4 Jan 2008 20:23:04 +0100 (CET) Date: Fri, 4 Jan 2008 20:23:04 +0100 From: Jeremie Le Hen To: Tiffany Snyder Message-ID: <20080104192304.GB76734@obiwan.tataz.chchile.org> References: <43B45EEF.6060800@x-trader.de> <43B47CB5.3C0F1632@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-net@freebsd.org, Andre Oppermann Subject: Re: Routing SMP benefit 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, 04 Jan 2008 20:00:58 -0000 On Fri, Dec 28, 2007 at 03:51:31PM -0800, Tiffany Snyder wrote: > Hi Andre, > are those numbers for small (64 bytes) packets? Good job on pushing > the base numbers higher on the same HW. > > What piqued my attention was the note that our forwarding > performance doesn't scale with multiple CPUs. Which means there's a lot of > work to be done :-) Have we taken a look at OpenSolaris' Surya > (http://www.opensolaris.org/os/community/networking/surya-design.pdf) > project? They allow multiple readers/single writer on the radix_node_head > (and not a mutex as we do) and we may be able to do the same to gain some > parallelism. There are other things in Surya that exploit multiple CPUs. > It's definitely worth a read. DragonFlyBSD seems to achieve parallelism by > classifying packet as flows and then redirecting the flows to different > CPUs. OpenSolaris also does something similar. We can definitely think along > those lines. > > NOTE: > 1) I said multiple instead of dual CPUs on purpose. > 2) I mentioned OpenSolaris and DragonFlyBSD as examples and to acknowledge > the work they are doing and to show that FreeBSD is far behind and is losing > it's lustre on continuing to be the networking platform of choice. A very good paper worth reading about all this by Paul Willmann, Scott Rixner and Alan Cox: An Evaluation of Network Stack Parallelism Strategies in Modern Operating Systems http://www.ece.rice.edu/~willmann/pubs/paranet_tr06-872.pdf -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Fri Jan 4 22:07:28 2008 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 2C4E616A418 for ; Fri, 4 Jan 2008 22:07:28 +0000 (UTC) (envelope-from cristclark@comcast.net) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id 0F1A213C442 for ; Fri, 4 Jan 2008 22:07:27 +0000 (UTC) (envelope-from cristclark@comcast.net) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id Z9lT1Y0020cQ2SL0A01S00; Fri, 04 Jan 2008 21:56:28 +0000 Received: from goku.pumpky.net ([24.6.98.159]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id Z9wC1Y00L3SKeAY8W00000; Fri, 04 Jan 2008 21:56:13 +0000 X-Authority-Analysis: v=1.0 c=1 a=7lkuuOZS6lhDCtfvDzYA:9 a=LhhjC-TvYlbI-hhxb3sA:7 a=Yqvue5ywzW5qU8oDAj0wjrBibHQA:4 a=kJVaTwQnZmMA:10 Received: from goku.pumpky.net (localhost. [127.0.0.1]) by goku.pumpky.net (8.13.8/8.13.8) with ESMTP id m04LuRYj089305 for ; Fri, 4 Jan 2008 13:56:27 -0800 (PST) (envelope-from cristclark@comcast.net) Received: (from cjc@localhost) by goku.pumpky.net (8.13.8/8.13.8/Submit) id m04LuQbY089304 for net@freebsd.org; Fri, 4 Jan 2008 13:56:27 -0800 (PST) (envelope-from cristclark@comcast.net) X-Authentication-Warning: goku.cjclark.org: cjc set sender to cristclark@comcast.net using -f Date: Fri, 4 Jan 2008 13:56:26 -0800 From: "Crist J. Clark" To: net@freebsd.org Message-ID: <20080104215626.GA88922@goku.pumpky.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-URL: http://people.freebsd.org/~cjc/ Cc: Subject: Text for IPv6 Scope X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Crist J. Clark" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 22:07:28 -0000 Anyone up for adding text to the scopeid field in the ifconfig(8) output for IPv6 addresses? Other OSes do. To avoid too much disruption to the current format, the text is appended after the currently printed hexadecimal field. Example: fxp0: flags=8843 mtu 1500 options=8 inet6 fe80::290:27ff:fe13:2540%fxp0 prefixlen 64 scopeid 0x5(site-local) While we're at it, update the in6.h file to include all scopes in RFC4291. Look OK? Anyone up for applying these? Patches (diffs off of a not-too-current CURRENT): Index: sbin/ifconfig/af_inet6.c =================================================================== RCS file: /ncvs/freebsd/src/sbin/ifconfig/af_inet6.c,v retrieving revision 1.5 diff -u -r1.5 af_inet6.c --- sbin/ifconfig/af_inet6.c 3 Feb 2007 03:40:33 -0000 1.5 +++ sbin/ifconfig/af_inet6.c 4 Jan 2008 21:53:26 -0000 @@ -290,8 +290,31 @@ if ((flags6 & IN6_IFF_TEMPORARY) != 0) printf("temporary "); - if (scopeid) - printf("scopeid 0x%x ", scopeid); + if (scopeid) { + printf("scopeid 0x%x", scopeid); + switch (scopeid) { + case __IPV6_ADDR_SCOPE_INTFACELOCAL: + printf("(interface-local) "); + break; + case __IPV6_ADDR_SCOPE_LINKLOCAL: + printf("(link-local) "); + break; + case __IPV6_ADDR_SCOPE_ADMINLOCAL: + printf("(admin-local) "); + break; + case __IPV6_ADDR_SCOPE_SITELOCAL: + printf("(site-local) "); + break; + case __IPV6_ADDR_SCOPE_ORGLOCAL: + printf("(org-local) "); + break; + case __IPV6_ADDR_SCOPE_GLOBAL: + printf("(global) "); + break; + default: + putchar(' '); + } + } if (ip6lifetime && (lifetime.ia6t_preferred || lifetime.ia6t_expire)) { printf("pltime "); Index: sys/netinet6/in6.h =================================================================== RCS file: /ncvs/freebsd/src/sys/netinet6/in6.h,v retrieving revision 1.44 diff -u -r1.44 in6.h --- sys/netinet6/in6.h 28 Mar 2006 12:51:22 -0000 1.44 +++ sys/netinet6/in6.h 4 Jan 2008 21:44:36 -0000 @@ -271,6 +271,7 @@ #define IPV6_ADDR_SCOPE_NODELOCAL 0x01 #define IPV6_ADDR_SCOPE_INTFACELOCAL 0x01 #define IPV6_ADDR_SCOPE_LINKLOCAL 0x02 +#define IPV6_ADDR_SCOPE_ADMINLOCAL 0x04 #define IPV6_ADDR_SCOPE_SITELOCAL 0x05 #define IPV6_ADDR_SCOPE_ORGLOCAL 0x08 /* just used in this file */ #define IPV6_ADDR_SCOPE_GLOBAL 0x0e @@ -278,6 +279,7 @@ #define __IPV6_ADDR_SCOPE_NODELOCAL 0x01 #define __IPV6_ADDR_SCOPE_INTFACELOCAL 0x01 #define __IPV6_ADDR_SCOPE_LINKLOCAL 0x02 +#define __IPV6_ADDR_SCOPE_ADMINLOCAL 0x04 #define __IPV6_ADDR_SCOPE_SITELOCAL 0x05 #define __IPV6_ADDR_SCOPE_ORGLOCAL 0x08 /* just used in this file */ #define __IPV6_ADDR_SCOPE_GLOBAL 0x0e -- Crist J. Clark | cjclark@alum.mit.edu From owner-freebsd-net@FreeBSD.ORG Sat Jan 5 00:47:53 2008 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 5256916A419 for ; Sat, 5 Jan 2008 00:47:53 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.freebsd.org (Postfix) with ESMTP id E40AA13C448 for ; Sat, 5 Jan 2008 00:47:52 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JAxCZ-0004fn-To; Sat, 05 Jan 2008 00:47:52 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JAwLm-0000PB-Fm; Sat, 05 Jan 2008 08:53:18 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18302.50925.780884.908062@roam.psg.com> Date: Sat, 5 Jan 2008 08:53:17 +0900 To: FreeBSD Net References: <18299.42791.826406.76763@roam.psg.com> Subject: Re: ath0 Ierrs 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, 05 Jan 2008 00:47:53 -0000 just for giggles i un-hacked the mtus and ran for an hour with no one using the wireless soek0.psg.com:/root# netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll vr0 1500 00:00:24:c8:b3:28 19022 0 16015 0 0 vr1 1500 00:00:24:c8:b3:29 0 0 51 0 0 vr2 1500 00:00:24:c8:b3:2a 20 0 66 0 0 vr3 1500 00:00:24:c8:b3:2b 15710 0 32628 0 0 ath0 1500 00:0b:6b:83:59:25 0 737819 185 0 0 lo0 16384 40 0 40 0 0 lo0 16384 fe80:6::1 fe80:6::1 0 - 0 - - lo0 16384 localhost ::1 0 - 0 - - lo0 16384 your-net localhost 42 - 42 - - bridg 1500 d6:3e:c6:9c:31:a7 15732 0 18559 0 0 bridg 1500 192.168.0.0 soek0 143 - 382 - - tun0 1454 18938 0 15926 0 0 tun0 1454 210.138.216.5 50.216.138.210.bn 1293 - 765 - - note the 737819 Ierrs with zero actually packets on the wire. how do i debug? this is a metrix CM9 miniPCI () in a soekris 5501 running very -current. ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0xa0010000-0xa001ffff irq 15 at device 17.0 on pci0 ath0: [ITHREAD] ath0: using obsoleted if_watchdog interface ath0: Ethernet address: 00:0b:6b:83:59:25 ath0: mac 5.9 phy 4.3 radio 3.6 how do i debug? randy From owner-freebsd-net@FreeBSD.ORG Sat Jan 5 07:40:41 2008 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 8209316A418 for ; Sat, 5 Jan 2008 07:40:41 +0000 (UTC) (envelope-from portcitycs@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.185]) by mx1.freebsd.org (Postfix) with ESMTP id 668F813C442 for ; Sat, 5 Jan 2008 07:40:41 +0000 (UTC) (envelope-from portcitycs@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so6889833rvb.43 for ; Fri, 04 Jan 2008 23:40:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=u6NVdgPG5a1zCNAzZXn3ce0CKl+gjVEpyHEPqhSxJQw=; b=GzpGXWWplTYs16cUYCLEmfNCbKoiT4MsnvjV19XDzRP2vyMF/AEb0jSQNqry1tYMp2xZI8NcKh32VtJb8v/FptOUBds7o6j2dgVsI4WIPwU9JkXQK5pcDiPs5irmjUbGqvom64ySjGLqLzR/npwoHqC0gx96Hrj5pW28EeXfSaw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=i4HWJ3dcLTjV+Df2CB77hCHI2++2L9W3/SbHjcwuiMgSk29YcJa69ioCKNDQyqTp3PzBgSVxOAi/2faIUzJ9T1Fir2+8sWiNSVYL4pFFBm/CBG02nLC0uyVsbNuX3sBNxuwxqESKXVlU9VX6HTHJTuZvZKux+QWE/YIkRVrs3nk= Received: by 10.142.89.9 with SMTP id m9mr3368343wfb.35.1199517298654; Fri, 04 Jan 2008 23:14:58 -0800 (PST) Received: by 10.142.238.2 with HTTP; Fri, 4 Jan 2008 23:14:58 -0800 (PST) Message-ID: <5a1835cd0801042314i29c830c9v15969c907f8818e7@mail.gmail.com> Date: Sat, 5 Jan 2008 02:14:58 -0500 From: "Lyle Scott III" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: IPSEC_NAT_T 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, 05 Jan 2008 07:40:41 -0000 i applied the patch from http://vanhu.free.fr/FreeBSD/patch-natt-freebsd6-2007-05-31.diff to get nat-t working with my racoon set up. Do I need 'option IPSEC_NAT_T' in my kernel or will it automatically be built? The reason I ask is when I apply the patch.. i sucessfully do a 'make buildword' but when i do a 'make buildkernel' it says the option is not found. Did i do something wrong or what? -- Lyle Scott, III http://www.lylescott.ws From owner-freebsd-net@FreeBSD.ORG Sat Jan 5 11:33:17 2008 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 86AA416A47A; Sat, 5 Jan 2008 11:33:17 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 754D713C447; Sat, 5 Jan 2008 11:33:17 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 7BE6982EFA; Sat, 5 Jan 2008 06:17:38 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Sat, 05 Jan 2008 06:17:38 -0500 X-Sasl-enc: fosk/a3d2CQqWCxPvEOWKl1nA73SkLLwH+b7XMZ0dUCR 1199531858 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id CABB027B83; Sat, 5 Jan 2008 06:17:37 -0500 (EST) Message-ID: <477F674F.7020706@FreeBSD.org> Date: Sat, 05 Jan 2008 11:17:35 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: "Crist J. Clark" References: <20080104215626.GA88922@goku.pumpky.net> In-Reply-To: <20080104215626.GA88922@goku.pumpky.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Text for IPv6 Scope 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, 05 Jan 2008 11:33:17 -0000 Crist J. Clark wrote: > Anyone up for adding text to the scopeid field in the ifconfig(8) > output for IPv6 addresses? Other OSes do. To avoid too much > disruption to the current format, the text is appended after the > currently printed hexadecimal field. > > Example: > > fxp0: flags=8843 mtu 1500 > options=8 > inet6 fe80::290:27ff:fe13:2540%fxp0 prefixlen 64 scopeid 0x5(site-local) > > While we're at it, update the in6.h file to include all scopes > in RFC4291. > > Look OK? Anyone up for applying these? > This kind of output might be cooler? fxp0: flags=8843 mtu 1500 options=8 inet6 fe80::290:27ff:fe13:2540%fxp0 prefixlen 64 scope site just my 2c BMS From owner-freebsd-net@FreeBSD.ORG Sat Jan 5 11:52:58 2008 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 6D89A16A47B; Sat, 5 Jan 2008 11:52:58 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id 855DA13C448; Sat, 5 Jan 2008 11:52:57 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from [192.168.1.198] (p508FCB03.dip.t-dialin.net [80.143.203.3]) by mail-n.franken.de (Postfix) with ESMTP id BAC8880000BD; Sat, 5 Jan 2008 12:52:54 +0100 (CET) (KNF-authenticated sender: macmic) Message-Id: <0AA9B264-8935-41E9-AC26-102ED6EE253C@lurchi.franken.de> From: Michael Tuexen To: "Crist J. Clark" In-Reply-To: <20080104215626.GA88922@goku.pumpky.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Sat, 5 Jan 2008 12:52:53 +0100 References: <20080104215626.GA88922@goku.pumpky.net> X-Mailer: Apple Mail (2.915) Cc: net@freebsd.org Subject: Re: Text for IPv6 Scope 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, 05 Jan 2008 11:52:58 -0000 Dear all, aren't site-local IPv6 addresses depreceated (RFC 3879)? So shouldn't the site-local stuff be removed? Best regards Michael On Jan 4, 2008, at 10:56 PM, Crist J. Clark wrote: > Anyone up for adding text to the scopeid field in the ifconfig(8) > output for IPv6 addresses? Other OSes do. To avoid too much > disruption to the current format, the text is appended after the > currently printed hexadecimal field. > > Example: > > fxp0: flags=8843 mtu 1500 > options=8 > inet6 fe80::290:27ff:fe13:2540%fxp0 prefixlen 64 scopeid > 0x5(site-local) > > While we're at it, update the in6.h file to include all scopes > in RFC4291. > > Look OK? Anyone up for applying these? > > Patches (diffs off of a not-too-current CURRENT): > > Index: sbin/ifconfig/af_inet6.c > =================================================================== > RCS file: /ncvs/freebsd/src/sbin/ifconfig/af_inet6.c,v > retrieving revision 1.5 > diff -u -r1.5 af_inet6.c > --- sbin/ifconfig/af_inet6.c 3 Feb 2007 03:40:33 -0000 1.5 > +++ sbin/ifconfig/af_inet6.c 4 Jan 2008 21:53:26 -0000 > @@ -290,8 +290,31 @@ > if ((flags6 & IN6_IFF_TEMPORARY) != 0) > printf("temporary "); > > - if (scopeid) > - printf("scopeid 0x%x ", scopeid); > + if (scopeid) { > + printf("scopeid 0x%x", scopeid); > + switch (scopeid) { > + case __IPV6_ADDR_SCOPE_INTFACELOCAL: > + printf("(interface-local) "); > + break; > + case __IPV6_ADDR_SCOPE_LINKLOCAL: > + printf("(link-local) "); > + break; > + case __IPV6_ADDR_SCOPE_ADMINLOCAL: > + printf("(admin-local) "); > + break; > + case __IPV6_ADDR_SCOPE_SITELOCAL: > + printf("(site-local) "); > + break; > + case __IPV6_ADDR_SCOPE_ORGLOCAL: > + printf("(org-local) "); > + break; > + case __IPV6_ADDR_SCOPE_GLOBAL: > + printf("(global) "); > + break; > + default: > + putchar(' '); > + } > + } > > if (ip6lifetime && (lifetime.ia6t_preferred || > lifetime.ia6t_expire)) { > printf("pltime "); > Index: sys/netinet6/in6.h > =================================================================== > RCS file: /ncvs/freebsd/src/sys/netinet6/in6.h,v > retrieving revision 1.44 > diff -u -r1.44 in6.h > --- sys/netinet6/in6.h 28 Mar 2006 12:51:22 -0000 1.44 > +++ sys/netinet6/in6.h 4 Jan 2008 21:44:36 -0000 > @@ -271,6 +271,7 @@ > #define IPV6_ADDR_SCOPE_NODELOCAL 0x01 > #define IPV6_ADDR_SCOPE_INTFACELOCAL 0x01 > #define IPV6_ADDR_SCOPE_LINKLOCAL 0x02 > +#define IPV6_ADDR_SCOPE_ADMINLOCAL 0x04 > #define IPV6_ADDR_SCOPE_SITELOCAL 0x05 > #define IPV6_ADDR_SCOPE_ORGLOCAL 0x08 /* just used in this file */ > #define IPV6_ADDR_SCOPE_GLOBAL 0x0e > @@ -278,6 +279,7 @@ > #define __IPV6_ADDR_SCOPE_NODELOCAL 0x01 > #define __IPV6_ADDR_SCOPE_INTFACELOCAL 0x01 > #define __IPV6_ADDR_SCOPE_LINKLOCAL 0x02 > +#define __IPV6_ADDR_SCOPE_ADMINLOCAL 0x04 > #define __IPV6_ADDR_SCOPE_SITELOCAL 0x05 > #define __IPV6_ADDR_SCOPE_ORGLOCAL 0x08 /* just used in this file */ > #define __IPV6_ADDR_SCOPE_GLOBAL 0x0e > -- > Crist J. Clark | cjclark@alum.mit.edu > _______________________________________________ > 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 Sat Jan 5 14:19:53 2008 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 0557D16A4D0; Sat, 5 Jan 2008 14:19:53 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id C954713C442; Sat, 5 Jan 2008 14:19:52 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 1B059209C; Sat, 5 Jan 2008 15:19:44 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id F0ACB207E; Sat, 5 Jan 2008 15:19:43 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id CCC2B844C3; Sat, 5 Jan 2008 15:19:43 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Sepherosa Ziehau" References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> <86abnovy4k.fsf@ds4.des.no> <86odc3dlgi.fsf@ds4.des.no> <86lk76c6t5.fsf@ds4.des.no> Date: Sat, 05 Jan 2008 15:19:43 +0100 In-Reply-To: (Sepherosa Ziehau's message of "Fri\, 4 Jan 2008 22\:20\:48 +0800") Message-ID: <864pds8idc.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 14:19:53 -0000 "Sepherosa Ziehau" writes: > This actually brings up two things: > 1) I think we should ignore seq in multicast frames; this is permitted in > 802.11 standard. In dfly I did that, since one of our users > encountered a broken commercial AP which is not 802.11e but uses > different seq for data and beacon. > 2) TX sequence. I think standards only mention QSTA/nQSTA, but not > AP. Currently our AP uses per node TX seq, which means beacon's seq > is difficult to choose, at least for 2560 based ral(4), whose beacons' > seq need to be set by software. I saw Linksys AP uses one seq for all > of the frames it sends. Sam, what's you opinion on this? > > I think if STA counts ral(4)'s beacon seq, as what we do currently, > beacon missing will quickly happen since beacons will be discarded > after first several data frames. OK, I *think* I understood most of that. Does this suggest a solution to you? I will try to get the wlandebug output tonight. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-net@FreeBSD.ORG Sat Jan 5 19:55:43 2008 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 4938E16A417; Sat, 5 Jan 2008 19:55:43 +0000 (UTC) (envelope-from mksmith@adhost.com) Received: from mail-defer01.adhost.com (mail-defer01.adhost.com [216.211.128.150]) by mx1.freebsd.org (Postfix) with ESMTP id 2E0D313C447; Sat, 5 Jan 2008 19:55:42 +0000 (UTC) (envelope-from mksmith@adhost.com) Received: from mail-in06.adhost.com (mail-in06.adhost.com [10.211.128.134]) by mail-defer01.adhost.com (Postfix) with ESMTP id 2F1FEED5C0; Sat, 5 Jan 2008 11:39:23 -0800 (PST) (envelope-from mksmith@adhost.com) Received: from ad-exh01.adhost.lan (unknown [216.211.143.69]) by mail-in06.adhost.com (Postfix) with ESMTP id D1AB7164858; Sat, 5 Jan 2008 11:39:22 -0800 (PST) (envelope-from mksmith@adhost.com) Received: from [192.168.100.101] ([10.142.3.67]) by ad-exh01.adhost.lan with Microsoft SMTPSVC(6.0.3790.3959); Sat, 5 Jan 2008 11:39:22 -0800 Message-Id: <8466A01A-B0B3-4163-BDD4-651F4AD1A08E@adhost.com> From: Michael Smith To: Michael Tuexen In-Reply-To: <0AA9B264-8935-41E9-AC26-102ED6EE253C@lurchi.franken.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Sat, 5 Jan 2008 11:39:21 -0800 References: <20080104215626.GA88922@goku.pumpky.net> <0AA9B264-8935-41E9-AC26-102ED6EE253C@lurchi.franken.de> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 05 Jan 2008 19:39:22.0255 (UTC) FILETIME=[ABB4F9F0:01C84FD2] X-TM-AS-Product-Ver: SMEX-7.5.0.1243-5.0.1023-15648.002 X-TM-AS-Result: No--11.593000-5.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: "Crist J. Clark" , net@freebsd.org Subject: Re: Text for IPv6 Scope 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, 05 Jan 2008 19:55:43 -0000 Hello All: I think we're crossing the streams here. The Site Local (FEC0::/10) has been deprecated. The fe80:: is Link Local and is very much alive. Regards, Mike On Jan 5, 2008, at 3:52 AM, Michael Tuexen wrote: > Dear all, > > aren't site-local IPv6 addresses depreceated (RFC 3879)? So shouldn't > the site-local stuff be removed? > > Best regards > Michael > > On Jan 4, 2008, at 10:56 PM, Crist J. Clark wrote: > >> Anyone up for adding text to the scopeid field in the ifconfig(8) >> output for IPv6 addresses? Other OSes do. To avoid too much >> disruption to the current format, the text is appended after the >> currently printed hexadecimal field. >> >> Example: >> >> fxp0: flags=8843 mtu 1500 >> options=8 >> inet6 fe80::290:27ff:fe13:2540%fxp0 prefixlen 64 scopeid >> 0x5(site-local) >> >> While we're at it, update the in6.h file to include all scopes >> in RFC4291. >> >> Look OK? Anyone up for applying these? >> >> Patches (diffs off of a not-too-current CURRENT): >> >> Index: sbin/ifconfig/af_inet6.c >> =================================================================== >> RCS file: /ncvs/freebsd/src/sbin/ifconfig/af_inet6.c,v >> retrieving revision 1.5 >> diff -u -r1.5 af_inet6.c >> --- sbin/ifconfig/af_inet6.c 3 Feb 2007 03:40:33 -0000 1.5 >> +++ sbin/ifconfig/af_inet6.c 4 Jan 2008 21:53:26 -0000 >> @@ -290,8 +290,31 @@ >> if ((flags6 & IN6_IFF_TEMPORARY) != 0) >> printf("temporary "); >> >> - if (scopeid) >> - printf("scopeid 0x%x ", scopeid); >> + if (scopeid) { >> + printf("scopeid 0x%x", scopeid); >> + switch (scopeid) { >> + case __IPV6_ADDR_SCOPE_INTFACELOCAL: >> + printf("(interface-local) "); >> + break; >> + case __IPV6_ADDR_SCOPE_LINKLOCAL: >> + printf("(link-local) "); >> + break; >> + case __IPV6_ADDR_SCOPE_ADMINLOCAL: >> + printf("(admin-local) "); >> + break; >> + case __IPV6_ADDR_SCOPE_SITELOCAL: >> + printf("(site-local) "); >> + break; >> + case __IPV6_ADDR_SCOPE_ORGLOCAL: >> + printf("(org-local) "); >> + break; >> + case __IPV6_ADDR_SCOPE_GLOBAL: >> + printf("(global) "); >> + break; >> + default: >> + putchar(' '); >> + } >> + } >> >> if (ip6lifetime && (lifetime.ia6t_preferred || >> lifetime.ia6t_expire)) { >> printf("pltime "); >> Index: sys/netinet6/in6.h >> =================================================================== >> RCS file: /ncvs/freebsd/src/sys/netinet6/in6.h,v >> retrieving revision 1.44 >> diff -u -r1.44 in6.h >> --- sys/netinet6/in6.h 28 Mar 2006 12:51:22 -0000 1.44 >> +++ sys/netinet6/in6.h 4 Jan 2008 21:44:36 -0000 >> @@ -271,6 +271,7 @@ >> #define IPV6_ADDR_SCOPE_NODELOCAL 0x01 >> #define IPV6_ADDR_SCOPE_INTFACELOCAL 0x01 >> #define IPV6_ADDR_SCOPE_LINKLOCAL 0x02 >> +#define IPV6_ADDR_SCOPE_ADMINLOCAL 0x04 >> #define IPV6_ADDR_SCOPE_SITELOCAL 0x05 >> #define IPV6_ADDR_SCOPE_ORGLOCAL 0x08 /* just used in this file */ >> #define IPV6_ADDR_SCOPE_GLOBAL 0x0e >> @@ -278,6 +279,7 @@ >> #define __IPV6_ADDR_SCOPE_NODELOCAL 0x01 >> #define __IPV6_ADDR_SCOPE_INTFACELOCAL 0x01 >> #define __IPV6_ADDR_SCOPE_LINKLOCAL 0x02 >> +#define __IPV6_ADDR_SCOPE_ADMINLOCAL 0x04 >> #define __IPV6_ADDR_SCOPE_SITELOCAL 0x05 >> #define __IPV6_ADDR_SCOPE_ORGLOCAL 0x08 /* just used in this file */ >> #define __IPV6_ADDR_SCOPE_GLOBAL 0x0e >> -- >> Crist J. Clark | cjclark@alum.mit.edu >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net- >> unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Jan 5 20:30:08 2008 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 C0CCF16A417; Sat, 5 Jan 2008 20:30:08 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from mx34.mail.ru (mx34.mail.ru [194.67.23.200]) by mx1.freebsd.org (Postfix) with ESMTP id 57BD513C455; Sat, 5 Jan 2008 20:30:08 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from [78.140.2.250] (port=2959 helo=nuclight.avtf.net) by mx34.mail.ru with esmtp id 1JBFeg-000FAk-00; Sat, 05 Jan 2008 23:30:06 +0300 Date: Sun, 06 Jan 2008 02:30:02 +0600 To: "Julian Elischer" References: <4772F123.5030303@elischer.org> <477416CC.4090906@elischer.org> <477D2EF3.2060909@elischer.org> From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <477D2EF3.2060909@elischer.org> User-Agent: Opera M2/7.54 (Win32, build 3865) Cc: arch@freebsd.org, Ivo Vachkov , Robert Watson , Qing Li , FreeBSD Net Subject: Re: resend: multiple routing table roadmap (format fix) 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, 05 Jan 2008 20:30:09 -0000 04.01.08 @ 00:52 Julian Elischer wrote: >>> By the way, I might add that in the 6.x compat. version I may end up >>> limiting the feature to 8 tables. This is because I need to store some >>> stuff in an efficient way in the mbuf, and in a compatible manner this >>> is easiest done by stealing the top 4 bits in the mbuf dlags word >>> and defining them as: >>> >>> #define M_HAVEFIB 0x10000000 >>> #define M_FIBMASK 0x07 >>> #define M_FIBNUM 0xe0000000 >>> #define M_FIBSHIFT 29 >>> #define m_getfib(_m, _default) ((m->m_flags & M_HAVE_FIBNUM) ? >>> ((m->m_flags >> M_FIBSHIFT) & M_FIBMASK) : _default) >>> #M_SETFIB(_m, _fib) do { \ >>> _m->m_flags &= ~M_FIBNUM; \ >>> _m->m_flags |= (M_HAVEFIB|((_fib & M_FIBMASK) << M_FIBSHIFT));\ >>> } while (0) >>> >>> This then becomes very easy to change to use a tag or >>> whatever is needed in later versions , and the number can >>> be expanded past 8 predefined FIBs at that time.. >> If you want it to be a tag, why spent bits in m_flags and not just do >> it as a tag at once? Or it is supposed to completely throw away 6.x >> (possibly 7.x too) implementation in favor of right thing in 8.0 ? > > basically yes.. > > I'm looking at just doing tags to start with, but haven't done it yet.. > I'm looking for a good bit of tag code to copy :-) Look at ipfw's O_ALTQ/O_TAG/O_TAGGED (ands some other parts), ng_tag.c, ng_ipfw.c, ng_ksocket.c and some other stuff :-) Tags are simple, if 16 bits are enough to you then even do not have to allocate data, just use tag_id member. Also they are easy to manipulate within netgraph with ng_tag, etc. But as drawback - you have to allocate memory for them, an as it is M_NOWAIT, malloc() can return NULL in interrupt threads... So a new field in mbuf (or flags) would be better in terms of performance, but it will break ABI :( I don't have m_tag_alloc() measurements, though. Doing 'ipfw add 1 tag 1 ip from any to any' on a 15 kpps 6.2 router didn't cause any noticeable slowdown while looking for half a minute at 'systat -vm 1'... > setfib 3 /bin/sh > > now by default everythign you do uses table 3. > or even > > setfib 3 jail {blah} > > and all the procs in the jail use table 3. You also need to do > setfib 3 jexec xxx > for extra processes you add to the jail afterwards. May be introduce a field in a struct prison to make it possible without additional commands? >>>>> 2/ packets received on an interface for forwarding. >>>>> By default these packets would use table 0, >>>>> (or possibly a number settable in a sysctl(not yet)). >>>>> but prior to routing the firewall can inspect them (see below). >>>>> >>>>> 3/ packets inspected by a packet classifier, which can arbitrarily >>>>> associate a fib with it on a packet by packet basis. >>>>> A fib assigned to a packet by a packet classifier >>>>> (such as ipfw) would over-ride a fib associated by >>>>> a more default source. (such as cases 1 or 2). >> Sounds good. I like idea to do routing decisions in firewall, to not >> double kernel code and userspace utilities, like in Linux' iproute2 >> (which, however, still have a few parameters and relies on firewall >> marks for others). However, there are some cases, I think, where it >> could be done outisde firewall. For example, make an ifconfig option to >> use a specific FIB as a default for all packets outgoing from this >> interface's address. But here arises another related question - Linux >> allows to select a specific src IP based on a routing table entry - >> destination address (thoughts about pf reply-to/route-ro, huh). > > that is default here too if I understand what you are talking about. > teh src address is selected from the routing table's exit interface. > In the code I'm showing in perforce, that address would depend on which > table your process was associated with. (or just the socket if you have > used the socket option on it before doing the bind/connect) What I'm talking about is adding possibility for future MPLS/VRF/etc. For example, if we make an interface option to use a specific FIB on that interface, for every incoming packet (put a tag on early input?), then ARP replies, ICMP redirects (yes, make stack to process them to particular FIB if specified, not to main) and so on will affect only this table. Then, it will be possible, say, to have 192.168.0.0/24 on em0 and also have 192.168.0.0/24 on em1, but that networks are completely independent of each other on both L2 and L3 (different customers) - after that, a change allowing to have the same IP address on different interfaces will lead to complete virtual independence. Without any vimages - why do we need separate TCP stacks etc. copies on a router without any jails, under a single administrator's control? Yes, this may be difficult with planned L2/L3 separation (currently ARP table is in fact part of FIB), but it is solvable - say, by binding an ARP table to one or several FIBs. Moreover, I think that complete stack virtulization in each jail/vimage is waste of resources - instead one or several FIBs/interfaces/ARP tables can be bound to each vimage/jail, possibly with write permissions. And even all of above is considered a far future and/or will be made different way, FIB binding to interface is still useful for (both incoming and) outgoing packets to make a firewall ruleset simpler. >> In relation to this I can remember multipath routing (different >> metrics?), addresses from one subnet on different ifaces (mask wider >> /32) and so on. >> Also it is interesting, how multiple FIBs would interact with host-wide >> events, such as ICMP redirects (which table should be updated?), >> storing of TCP stack metrics (MTU, etc.) and hostcache, and so on. How >> these and above will be solved?.. > > I'm not really too knowledgeable about multicast.. Is multicast and multipath routing the same? >> per ifconfig (>1 host per subnet)/icmp redirects/src to prefer, >> multipath/metrics, tcp stack parameters interaction, iproute2 > > I'm not trying to solve problems that need vimage to solve them.. Umm, what vimage?.. :) I forgot to clear these keywords written for myself when writing draft and expaining them in detail,sorry :) >>>>> Routing messages would be associated with their >>>>> process, and thus select one FIB or another. >> This is not clear. How should the 'route' command work with different >> FIBs, if they are supposed by admin to be used for forwarding, and not >> the straight per-process? I think a setfib option is more consistent >> than running route under setfib command. Also, routing sockets and >> routing daemons - should they work with only one table?.. > > if you do > setfib 3 route get 1.1.1.1 > > you may get a different result from > > setfib 2 route get 1.1.1.1 > > I will add a fibnum argument to route itself as well but it's not needed > immediately as long as I have the setfib command. OK, but we should think about it in the future. In theory, routing socket's messages are easily extendable with FIB number in uint16_t, as message keeps it's length... >>>>> I have not yet added the changes to ipfw. >> Action modifier, like 'ipfw add count setfib 3 ip from any to any' ? >> There were thoughts (I heard,t as a hack before multiple FIBs) about >> making an additional, say, 'nexthop' ipfw action, which acts like fwd, >> but does not accept packet, allowing to continue it through firewall >> ruleset - thus making it more comfortable to separate routing (imagine >> 'nexthop tablearg') and filtering. There are questions with both fwd >> and new supposed option: will fwd still survive? Will it change the >> output interface, like as complete rerouting before calling pfil(9) >> hooks, so that *oif will be changed to be mathed iin rules below? pf >> route-to/reply-to is hanging around... > > The 'nexthop' cal you suggest is problematic because it needs to return > information immediately. which is why it is terminal. Um, why? Why it can't continue through ruleset? I don't know implementation details of routing and 'ipfw fwd', alas, > As for the setfib ipfw action, I have now done this in p4. > > ipfw add 200 setfib 3 ip from any to any in receive em0 > > now works. > This lessens the need for associating a fib with an interface as the > firewall can do that too.. > > the setfib rule is not terminal. (hmm need to check I did that right.) Oh, it it works, that's cool. > you can also do > ipfw add 200 skipto 300 ip from any to any hasfib > # to select on a packet that has a fib associated with it already. > ipfw add 200 skipto 300 ip from any to any fib 4 > # to slelect packets that are associated with fib 4 > ipfw add 200 clrfib ip from any to any > # to remove a fib association from the packet. Do we need a separate keyword 'clrfib' while it could be 'setfib 0' ? Or at least save one opcode in kernel's ipfw. Also, it would be nice to have 'setfib tablearg' together with reserving 16 bits for FIB number - some systems with hundreds of vlans will want to have more than 256 tables, I think... >>>>> Interaction with the ARP layer/ LL layer would need to be >>>>> revisited as well. Qing Li has been working on this already. >> Oh yes, L2 interaction is interesting. How it should work in case of >> planned separation of routing and ARP tables?.. I've explained my views about it above... -- WBR, Vadim Goncharov From owner-freebsd-net@FreeBSD.ORG Sat Jan 5 20:57:08 2008 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 1282416A418 for ; Sat, 5 Jan 2008 20:57:08 +0000 (UTC) (envelope-from synfinatic@gmail.com) Received: from hs-out-2122.google.com (hs-out-0708.google.com [64.233.178.249]) by mx1.freebsd.org (Postfix) with ESMTP id CD23213C46A for ; Sat, 5 Jan 2008 20:57:07 +0000 (UTC) (envelope-from synfinatic@gmail.com) Received: by hs-out-2122.google.com with SMTP id j58so5718866hsj.11 for ; Sat, 05 Jan 2008 12:57:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=4+D7rEkJZA5FIKP21q/yko2ZDY2dAI6U4hRlieknmAM=; b=oV1BkW+ZykfuYfFf402wFEUZKLRkrF6jfBY+bnd/dAIyb9V6CkYPr1fq5KL5XxAStAZ6AcnANt+UdwbiUYJLONbcQ/7n3PPvQULPejQVpF41WPocJso73cWDVErCH0IEpRxZermyUTO55fStm9l8EZ9OETpKloqYtKqYa3EG0DI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Vmma3wAqQwxkXjFHy6LGYmAJ7zeizClZvdh9jWe9yYMd+O7hoUarZpaq2rjmUa4Md9JyMyPAuqJ81k5MtsxUr8d1Q7C3SKjWsblZ3w+y9wWtCiGDNGfQQwxKTTh79RgnzraoymOtGFW1btGjhF2nPNkZyumsbvg9nZwpqIKkJds= Received: by 10.150.149.19 with SMTP id w19mr5016761ybd.52.1199565043864; Sat, 05 Jan 2008 12:30:43 -0800 (PST) Received: by 10.151.84.9 with HTTP; Sat, 5 Jan 2008 12:30:43 -0800 (PST) Message-ID: <1ca1c1410801051230l49fa523cicb3f9f9394214701@mail.gmail.com> Date: Sat, 5 Jan 2008 12:30:43 -0800 From: "Aaron Turner" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: looking for dual-phy (copper & fiber) 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: Sat, 05 Jan 2008 20:57:08 -0000 Sorry for the slightly OT, but I've run out of ideas... I could of sworn about a month ago or so, I found a half-height gigabit NIC (PCI Express I think) which offered two copper AND two SFP connectors for fiber. The card had only two ethernet controllers (Marvell I think), hence you could only use up to two connectors at any time. Very similar to many switches which give you the choice of copper or fiber but not both (sometimes called "combo ports"). Of course, I didn't bookmark the page, I can't find it in my browser history and Google is failing me horribly. Note: I'm NOT looking for the old SysKonnect or Allied Tellysn cards which are 10/100Mbps. This was a gigabit card! Any hints or pointers to the page, vendor or reseller would be greatly appreciated. Thanks, Aaron -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin From owner-freebsd-net@FreeBSD.ORG Sat Jan 5 21:55:22 2008 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 0C84A16A419 for ; Sat, 5 Jan 2008 21:55:22 +0000 (UTC) (envelope-from portcitycs@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id E362813C474 for ; Sat, 5 Jan 2008 21:55:21 +0000 (UTC) (envelope-from portcitycs@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so11889657waf.3 for ; Sat, 05 Jan 2008 13:55:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=MawsS9GxZDxz1FjC5y57AJqUUyqvNUwbMi0C6TR0PgI=; b=t516pmq+h8+O4PbhdSsbZg2zrNmyY5mCaAf2esjoMQglmQtPu2wBdn8iCw4bQzFQyb9vhn/rjQGU088SA4AZTpBuhughIGylGEKW5L2K168yayMJSGkuwtf8bQzol3+6C1vC3hdODaWBNuhUDQRIt7nHSlp4mwlren86DKnIIKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=gCmLxhU0Fb9MQ0U9gt46ePQIMIXKcaktj7q2pw6ALg7kur811R5kVLxDgEyfKo1TrAJdTFnVM6jLGDFKWYCRC1FBl24ev0k3GO0+6oV3vm4LsujuCFQggPe5gM6bnBh/EUQhPPH70unkxLYT6MI26fMDh+wwzKcHIDJXoBIFK4s= Received: by 10.142.131.18 with SMTP id e18mr5623278wfd.147.1199570121237; Sat, 05 Jan 2008 13:55:21 -0800 (PST) Received: by 10.142.238.2 with HTTP; Sat, 5 Jan 2008 13:55:21 -0800 (PST) Message-ID: <5a1835cd0801051355tc14f06bja72d8659bd499861@mail.gmail.com> Date: Sat, 5 Jan 2008 16:55:21 -0500 From: "Lyle Scott III" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ipsec_tools will not compile after IPSEC_NAT_T 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: Sat, 05 Jan 2008 21:55:22 -0000 I applied the IPSEC_NAT_T patch from http://vanhu.free.fr/FreeBSD/patch-natt-freebsd6-2007-05-31.diff to FreeBSD 6.2-release-p9 yesterday to include IPSEC_NAT_T support. i did a make buildworld buildkernel && make installworld installkernel && shutdown -r now Now when i recompile /usr/ports/security/ipsec-tools it passes the test for checking if the nat_t patch is installed but the port fails in make. I did some research and noticed the same function it errors at is in the patch. Did i mess something up or what? I'm not sure where to go from here. Should i just delete /usr/src/* and extract a new src and start over? cc -DHAVE_CONFIG_H -I. -I../.. -I./../libipsec -I./../../src/racoon/missing -D_GNU_SOURCE -DSYSCONFDIR=\"/usr/local/etc/racoon\" -DADMINPORTDIR=\"/var/db/racoon\" -pipe -g -Wall -Werror -Wno-unused -MT isakmp.o -MD -MP -MF .deps/isakmp.Tpo -c -o isakmp.o isakmp.c isakmp.c: In function `isakmp_open': isakmp.c:1750: error: `UDP_ENCAP_ESPINUDP' undeclared (first use in this function) isakmp.c:1750: error: (Each undeclared identifier is reported only once isakmp.c:1750: error: for each function it appears in.) isakmp.c:1753: error: `UDP_ENCAP_ESPINUDP_NON_IKE' undeclared (first use in this function) isakmp.c:1757: error: `UDP_ENCAP' undeclared (first use in this function) *** Error code 1 Stop in /usr/ports/security/ipsec-tools/work/ipsec-tools-0.7/src/racoon. *** Error code 1 Stop in /usr/ports/security/ipsec-tools/work/ipsec-tools-0.7/src. *** Error code 1 Stop in /usr/ports/security/ipsec-tools/work/ipsec-tools-0.7. *** Error code 1 Stop in /usr/ports/security/ipsec-tools/work/ipsec-tools-0.7. *** Error code 1 Stop in /usr/ports/security/ipsec-tools. *** Error code 1 -- Lyle Scott, III http://www.lylescott.ws