From owner-freebsd-net@FreeBSD.ORG Sun Nov 11 06:44:22 2007 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 D57CB16A419 for ; Sun, 11 Nov 2007 06:44:22 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with SMTP id 842BA13C4A8 for ; Sun, 11 Nov 2007 06:44:22 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 15159 invoked by uid 399); 11 Nov 2007 06:17:20 -0000 Received: from localhost (HELO slave.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 11 Nov 2007 06:17:20 -0000 X-Originating-IP: 127.0.0.1 Date: Sat, 10 Nov 2007 22:17:18 -0800 (PST) From: Doug Barton To: Bob Johnson In-Reply-To: <54db43990711051446y6399b822p6ba9dbb86b65771b@mail.gmail.com> Message-ID: References: <20070329182906.GB38703@rogue.navcom.lan> <20070405154644.GB1844@rogue.navcom.lan> <20070517131713.GE3228@rogue.navcom.lan> <1194301190.75993.3.camel@terra> <54db43990711051446y6399b822p6ba9dbb86b65771b@mail.gmail.com> User-Agent: Alpine 0.99999 (BSF 796 2007-11-08) X-message-flag: Outlook -- Not just for spreading viruses anymore! X-OpenPGP-Key-ID: 0xD5B2F0FB Organization: http://www.FreeBSD.org/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, mtm@freebsd.org, freebsd-rc@freebsd.org Subject: Re: Merging rc.d/network_ipv6 into rc.d/netif X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2007 06:44:22 -0000 On Mon, 5 Nov 2007, Bob Johnson wrote: > On 11/5/07, Mike Makonnen wrote: > >> Most IP related knobs will have an ipv4_ and ipv6_ version. To make the >> transition easier rc.subr(8) will "automagically" DTRT for the following >> knobs: >> gateway_enable => ipv4_gateway_enable >> router_enable => ipv4_router_enable >> router => ipv4_router >> router_flags => ipv4_router_flags >> defaultrouter => ipv4_defaultrouter >> static_routes => ipv4_static_routes >> static_routes_ => ipv4_static_routes_ >> route_ => ipv4_route_ >> dhclient_program => ipv4_dhclient_program >> dhclient_flags => ipv4_dhclient_flags >> dhclient_flags_ => ipv4_dhclient_flags_ >> background_dhclient_ => ipv4_background_dhclient_ >> >> Please try it and let me know what you think. > > Personally, I'd prefer the new names be along the lines of > ifconfig__ipv4, ifconfig__ipv6, > defaultrouter_ipv4, defaultrouter_ipv6, dhclient_program_ipv4, > dhclient_program_ipv6, etc. Personally I think that grouping things by ipv4/ipv6 makes more sense, and has better longevity. > And this would be a good time to change defaultrouter to default_router! Or we could make it shorter and call it gateway. Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Sun Nov 11 11:19:26 2007 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 55E1216A46E; Sun, 11 Nov 2007 11:19:26 +0000 (UTC) (envelope-from mtm@FreeBSD.Org) Received: from terra.mike.lan (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1862E13C4B2; Sun, 11 Nov 2007 11:19:23 +0000 (UTC) (envelope-from mtm@FreeBSD.Org) Received: by terra.mike.lan (Postfix, from userid 1000) id EAB1767DE0; Sun, 11 Nov 2007 14:23:32 +0300 (EAT) From: Mike Makonnen To: Doug Barton In-Reply-To: References: <20070329182906.GB38703@rogue.navcom.lan> <20070405154644.GB1844@rogue.navcom.lan> <20070517131713.GE3228@rogue.navcom.lan> <1194301190.75993.3.camel@terra> <54db43990711051446y6399b822p6ba9dbb86b65771b@mail.gmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sun, 11 Nov 2007 14:23:31 +0300 Message-Id: <1194780211.33352.6.camel@terra> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 FreeBSD GNOME Team Port Cc: Bob Johnson , freebsd-net@freebsd.org, mtm@freebsd.org, freebsd-rc@freebsd.org Subject: Re: Merging rc.d/network_ipv6 into rc.d/netif X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mtm@FreeBSD.Org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2007 11:19:26 -0000 On Sat, 2007-11-10 at 22:17 -0800, Doug Barton wrote: > On Mon, 5 Nov 2007, Bob Johnson wrote: > > > > > Personally, I'd prefer the new names be along the lines of > > ifconfig__ipv4, ifconfig__ipv6, > > defaultrouter_ipv4, defaultrouter_ipv6, dhclient_program_ipv4, > > dhclient_program_ipv6, etc. > > Personally I think that grouping things by ipv4/ipv6 makes more sense, and > has better longevity. > Frankly, I don't mind either way. I used the current scheme because that's how the current ipv6 knobs are organized. > > And this would be a good time to change defaultrouter to default_router! > > Or we could make it shorter and call it gateway. Changing it at this late date is probably just gratuitous. FYI, there's a slightly updated patch back up at: http://people.freebsd.org/~mtm/src-etc.ipv6.diff Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mmakonnen @ gmail.com | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm @ FreeBSD.Org | FreeBSD - http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Sun Nov 11 16:26:02 2007 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 1018A16A47E for ; Sun, 11 Nov 2007 16:26:02 +0000 (UTC) (envelope-from MartinKulas@sosend.de) Received: from www70.your-server.de (www70.your-server.de [213.133.104.70]) by mx1.freebsd.org (Postfix) with ESMTP id C87F013C4B0 for ; Sun, 11 Nov 2007 16:26:01 +0000 (UTC) (envelope-from MartinKulas@sosend.de) Received: from [91.16.252.125] (helo=example.net) by www70.your-server.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52) id 1IrFFy-0004a8-Mw for freebsd-net@FreeBSD.org; Sun, 11 Nov 2007 17:01:55 +0100 Received: by example.net (nbSMTP-1.00) for uid 1001 (using TLSv1/SSLv3 with cipher AES256-SHA (256/256 bits)) MartinKulas@sosend.de; Sun, 11 Nov 2007 17:02:01 +0100 (CET) Date: Sun, 11 Nov 2007 17:01:57 +0100 From: Martin Kulas To: freebsd-net@FreeBSD.org Message-ID: <20071111160157.GA1230@thunderbird.tld> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Sender: MartinKulas@sosend.de X-PGP-Key: http://sosend.de/mk/coolaz_web_de.pub.asc X-Authenticated-Sender: martinkulas@sosend.de X-Virus-Scanned: Clear (ClamAV 0.91.1/3707/Fri Jul 20 18:08:45 2007) Cc: Subject: [netgraph] Access to loopback device X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2007 16:26:02 -0000 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello! While playing around with netgraph I am wondering if there is a node to=20 access the loopback device lo0. I want to treat lo0 like a ng_ether node= =20 where I can use the `lower` hook to get ethernet frames. Is there a netgraph node to get all packets which goes through the=20 loopback device? I did a quick search in netgraph(4) but I did not=20 find anything. Thanks in advance, Martin --=20 PGP Key: http://sosend.de/mk/MartinKulas_sosend_de.pub.asc --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHNyd119IqVEKqLGwRArBcAJ4r0MmH/YQFXgB0w3gQlDq+rXU01gCeIZ05 Hg+6XO6bsvGEIeWm0H3hSsk= =Ui+V -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu-- From owner-freebsd-net@FreeBSD.ORG Sun Nov 11 17:48:24 2007 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 436AB16A628; Sun, 11 Nov 2007 17:48:24 +0000 (UTC) (envelope-from xride@x12.dk) Received: from cicero-fbr1.cybercity.dk (cicero-fbr1.cybercity.dk [212.242.40.5]) by mx1.freebsd.org (Postfix) with ESMTP id EEBD113C4E3; Sun, 11 Nov 2007 17:48:23 +0000 (UTC) (envelope-from xride@x12.dk) Received: from cicero4.cybercity.dk (cicero4.cybercity.dk [212.242.40.52]) by cicero-fbr1.cybercity.dk (Postfix) with ESMTP id 13F643D2E72; Sun, 11 Nov 2007 18:03:38 +0100 (CET) Received: from beacon.x12.dk (0x5550f21e.adsl.cybercity.dk [85.80.242.30]) by cicero4.cybercity.dk (Postfix) with ESMTP id 539343CC391; Sun, 11 Nov 2007 18:03:23 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by beacon.x12.dk (Postfix) with ESMTP id 2F82728417; Sun, 11 Nov 2007 18:03:39 +0100 (CET) Date: Sun, 11 Nov 2007 18:02:56 +0100 From: Soeren Straarup To: Doug Barton Message-ID: <20071111180256.07c41270@x12.dk> In-Reply-To: References: <20070329182906.GB38703@rogue.navcom.lan> <20070405154644.GB1844@rogue.navcom.lan> <20070517131713.GE3228@rogue.navcom.lan> <1194301190.75993.3.camel@terra> <54db43990711051446y6399b822p6ba9dbb86b65771b@mail.gmail.com> X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Bob Johnson , freebsd-net@freebsd.org, mtm@freebsd.org Subject: Re: Merging rc.d/network_ipv6 into rc.d/netif X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2007 17:48:24 -0000 On Sat, 10 Nov 2007 22:17:18 -0800 (PST) Doug Barton wrote: > On Mon, 5 Nov 2007, Bob Johnson wrote: > > > On 11/5/07, Mike Makonnen wrote: > > > >> Most IP related knobs will have an ipv4_ and ipv6_ version. To > >> make the transition easier rc.subr(8) will "automagically" DTRT > >> for the following knobs: > >> gateway_enable => ipv4_gateway_enable > >> router_enable => ipv4_router_enable > >> router => ipv4_router > >> router_flags => ipv4_router_flags > >> defaultrouter => ipv4_defaultrouter > >> static_routes => ipv4_static_routes > >> static_routes_ => ipv4_static_routes_ > >> route_ => ipv4_route_ > >> dhclient_program => ipv4_dhclient_program > >> dhclient_flags => ipv4_dhclient_flags > >> dhclient_flags_ => ipv4_dhclient_flags_ > >> background_dhclient_ => ipv4_background_dhclient_ > >> > >> Please try it and let me know what you think. > > > > Personally, I'd prefer the new names be along the lines of > > ifconfig__ipv4, ifconfig__ipv6, > > defaultrouter_ipv4, defaultrouter_ipv6, dhclient_program_ipv4, > > dhclient_program_ipv6, etc. > > Personally I think that grouping things by ipv4/ipv6 makes more > sense, and has better longevity. > > > And this would be a good time to change defaultrouter to > > default_router! > > Or we could make it shorter and call it gateway. Well there is a difference between router and gateway. I think that gateway would be a better word since from my understanding that is what people use today. /Soeren -- Soeren Straarup | aka OZ2DAK aka Xride FreeBSD committer | FreeBSD since 2.2.6-R If a program is not working right, then send a patch From owner-freebsd-net@FreeBSD.ORG Sun Nov 11 18:27:40 2007 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 BA6A816A480; Sun, 11 Nov 2007 18:27:40 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.freebsd.org (Postfix) with ESMTP id C20D913C4A7; Sun, 11 Nov 2007 18:27:39 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from localhost (marvin-mail [192.168.0.2]) by marvin.harmless.hu (Postfix) with ESMTP id E89337BFF50; Sun, 11 Nov 2007 18:53:39 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at harmless.hu Received: from marvin.harmless.hu ([192.168.0.2]) by localhost (marvin.harmless.hu [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id BpSVjrC9qWjy; Sun, 11 Nov 2007 18:53:39 +0100 (CET) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id A721D7BFC3E; Sun, 11 Nov 2007 18:53:37 +0100 (CET) Date: Sun, 11 Nov 2007 18:53:36 +0100 From: Gergely CZUCZY To: Soeren Straarup Message-ID: <20071111175336.GA3345@harmless.hu> References: <20070329182906.GB38703@rogue.navcom.lan> <20070405154644.GB1844@rogue.navcom.lan> <20070517131713.GE3228@rogue.navcom.lan> <1194301190.75993.3.camel@terra> <54db43990711051446y6399b822p6ba9dbb86b65771b@mail.gmail.com> <20071111180256.07c41270@x12.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: <20071111180256.07c41270@x12.dk> User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: Bob Johnson , freebsd-net@freebsd.org, mtm@freebsd.org, Doug Barton Subject: Re: Merging rc.d/network_ipv6 into rc.d/netif X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2007 18:27:40 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 11, 2007 at 06:02:56PM +0100, Soeren Straarup wrote: > On Sat, 10 Nov 2007 22:17:18 -0800 (PST) > Doug Barton wrote: >=20 > > On Mon, 5 Nov 2007, Bob Johnson wrote: > >=20 > > > On 11/5/07, Mike Makonnen wrote: > > > > > >> Most IP related knobs will have an ipv4_ and ipv6_ version. To > > >> make the transition easier rc.subr(8) will "automagically" DTRT > > >> for the following knobs: > > >> gateway_enable =3D> ipv4_gateway_enable > > >> router_enable =3D> ipv4_router_enable > > >> router =3D> ipv4_router > > >> router_flags =3D> ipv4_router_flags > > >> defaultrouter =3D> ipv4_defaultrouter > > >> static_routes =3D> ipv4_static_routes > > >> static_routes_ =3D> ipv4_static_routes_ > > >> route_ =3D> ipv4_route_ > > >> dhclient_program =3D> ipv4_dhclient_program > > >> dhclient_flags =3D> ipv4_dhclient_flags > > >> dhclient_flags_ =3D> ipv4_dhclient_flags_ > > >> background_dhclient_ =3D> ipv4_background_dhclient_ > > >> > > >> Please try it and let me know what you think. > > > > > > Personally, I'd prefer the new names be along the lines of > > > ifconfig__ipv4, ifconfig__ipv6, > > > defaultrouter_ipv4, defaultrouter_ipv6, dhclient_program_ipv4, > > > dhclient_program_ipv6, etc. > >=20 > > Personally I think that grouping things by ipv4/ipv6 makes more > > sense, and has better longevity. > >=20 > > > And this would be a good time to change defaultrouter to > > > default_router! > >=20 > > Or we could make it shorter and call it gateway. >=20 > Well there is a difference between router and gateway. > I think that gateway would be a better word since from my > understanding that is what people use today. +1 vote for the "gateway". I always wandered why it's called "router", since "gateway" would be a more proper name for it. Sincerely, Gergely Czuczy mailto: gergely.czuczy@harmless.hu --=20 Weenies test. Geniuses solve problems that arise. --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) owF9Vs1v40QUL/shgSUOlfgDHkFid6nt2mnTdkMbut2yVZHKRjRiK4EUTeyxM6o9 Y2bGCdkDXPeAEOK6EuwBiQMCcVhpb3CBKwf+hD1xXAlx4sIbO0kTN8FSHPu9+f3e 17w3/urVqytXVv/4+elHa198/filH1/+p/dWmmvNYyclcsC443ue72xsbDacTWej sU3qfo/6QRhF4fbto+07394VXFOunc4oo03Q9FO9niWE8bch6BOpqN7LdeTsWJN1 h0xlQjHNBG8C4wnjdKrrSMJVRKXzLg9EyHjchE9yoWnoZJJxTXoJtaz7HE5zbsP7 YgC+b0Pd87aBaPC2ml692dhqn8Cah17bcCqopLhaS0JknsFQIlfTaoGhINoG3ytY CoZ6velvN/0dcLwdz4Ob7dPOLVx6KPIYDojUgsNuiC+9/XuS0oPTQ1fIuDXl3Kt7 uLqgPhHoXWPKbMOB6MF7os8Vckx9mCIKjO+vN9bN2hN2TuGEnAvO0fXdVKf7Edrr qXDengGW9xYaVBqO2yBpQjBZcM5FT8GQJQn0yYAC4cCywWYXH0LztNWFAZUKK+BC R0xYUoKWdR9/pgpFgYASxagEGbgq78mbO7dK1hrJtUhJzAKSJKMaHHY+6ExoIiEL lkgkiRhiDUt3mhP95IrR1SEZdSk3ZS1EexuHrdLTeWUVKkWuqZxFzkDnlIuRMHtV kUuMRQmJ1RJIqawCQxqRPNGzJi+Ac8oqUmmiWVCSqypyTvm/yO7u8b3WMmShXBhr d/fs7Gwqq8RaKi+F2g8Shg3czaSIJUnnQ60ol4IvUrwAvDjFc9pqvAu0VYIeCc5j DIyHF6srLMuWjKkmjO0Ee8X0zgiYLhotoRpSanb/EIZ9HFAjkWNnMH7uzrYvtLEV BTeNZMPxjRAySXEEFj3E6RA4SXET9LCLE4HNZMRmZioQ0ZiARYHgEYu7uzgjqYxI QFtd47u9VLVlj7Fz+3AMuiTbsi9VuFw6IVmgRAzVgTs76C4CheMyEXjHvJjsZqyI De8Y66jI/LphKaaSglTIspcV5YraRX77xKRFm+YymaEDpkfu/GC9g8uQFGehyJOw SCLEQqCQYWW0MEcUIiutqsV8csZd/vos930JQwpBQVsMTiy66gtp8MY5MxiNbDzI 3MkB8YCiHGsoEaHQm5BFkTmkAmpiGVKc+WMvDMsFupKxUj4b1jgTQyFDUMzwRVKk kI4Qi3sXU6+RscwyMpicmP+MigxnaG62rgiNqTUfBnjETOd4bWys5qIPJMEnhBLD iCfNsG+2+w1VxEtDq1Y6X7PHPkzBs66aYuIuFxn6a3Z3YYpp18Lr1MDwHBvZlnVE ZYxPcPdhHjwcWSlhiRZNiEuxGxTiffzISBOqlNvPLctxTJofYBoZ7hocc9qFI3zB +BQokQwKw3gwpKrMA5FMUdd69M7V6yvma2byJbR65dr3K09+eP78Rfuzf/urbzSP +Wu/Prn93Z9/rTy+9vnGo+sv/v7491ee/vLhm18+++a3n579Bw== =dPqe -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 12 00:37:30 2007 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 AC49716A418 for ; Mon, 12 Nov 2007 00:37:30 +0000 (UTC) (envelope-from ecrist@secure-computing.net) Received: from snipe.secure-computing.net (snipe.secure-computing.net [209.240.66.149]) by mx1.freebsd.org (Postfix) with ESMTP id 66CBD13C4AA for ; Mon, 12 Nov 2007 00:37:30 +0000 (UTC) (envelope-from ecrist@secure-computing.net) Received: from [192.168.1.200] (unknown [209.240.66.157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ecrist@secure-computing.net) by snipe.secure-computing.net (Postfix) with ESMTP id 5813717043; Sun, 11 Nov 2007 18:37:07 -0600 (CST) Message-Id: From: Eric F Crist To: Gergely CZUCZY In-Reply-To: <20071111175336.GA3345@harmless.hu> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Date: Sun, 11 Nov 2007 18:37:06 -0600 References: <20070329182906.GB38703@rogue.navcom.lan> <20070405154644.GB1844@rogue.navcom.lan> <20070517131713.GE3228@rogue.navcom.lan> <1194301190.75993.3.camel@terra> <54db43990711051446y6399b822p6ba9dbb86b65771b@mail.gmail.com> <20071111180256.07c41270@x12.dk> <20071111175336.GA3345@harmless.hu> X-Mailer: Apple Mail (2.912) Cc: Bob Johnson , freebsd-net@freebsd.org, mtm@freebsd.org, Doug Barton , Soeren Straarup Subject: Re: Merging rc.d/network_ipv6 into rc.d/netif X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2007 00:37:30 -0000 On Nov 11, 2007, at 11:53 AM, Gergely CZUCZY wrote: > On Sun, Nov 11, 2007 at 06:02:56PM +0100, Soeren Straarup wrote: >> On Sat, 10 Nov 2007 22:17:18 -0800 (PST) >> Doug Barton wrote: >> >>> On Mon, 5 Nov 2007, Bob Johnson wrote: >>> >>>> On 11/5/07, Mike Makonnen wrote: >>>> >>>>> Most IP related knobs will have an ipv4_ and ipv6_ version. To >>>>> make the transition easier rc.subr(8) will "automagically" DTRT >>>>> for the following knobs: >>>>> gateway_enable => ipv4_gateway_enable >>>>> router_enable => ipv4_router_enable >>>>> router => ipv4_router >>>>> router_flags => ipv4_router_flags >>>>> defaultrouter => ipv4_defaultrouter >>>>> static_routes => ipv4_static_routes >>>>> static_routes_ => ipv4_static_routes_ >>>>> route_ => ipv4_route_ >>>>> dhclient_program => ipv4_dhclient_program >>>>> dhclient_flags => ipv4_dhclient_flags >>>>> dhclient_flags_ => ipv4_dhclient_flags_ >>>>> background_dhclient_ => ipv4_background_dhclient_ >>>>> >>>>> Please try it and let me know what you think. >>>> >>>> Personally, I'd prefer the new names be along the lines of >>>> ifconfig__ipv4, ifconfig__ipv6, >>>> defaultrouter_ipv4, defaultrouter_ipv6, dhclient_program_ipv4, >>>> dhclient_program_ipv6, etc. >>> >>> Personally I think that grouping things by ipv4/ipv6 makes more >>> sense, and has better longevity. >>> >>>> And this would be a good time to change defaultrouter to >>>> default_router! >>> >>> Or we could make it shorter and call it gateway. >> >> Well there is a difference between router and gateway. >> I think that gateway would be a better word since from my >> understanding that is what people use today. > +1 vote for the "gateway". I always wandered why it's called > "router", since "gateway" would be a more proper name for it. +1 vote for "gateway". ----- Eric F Crist Secure Computing Networks From owner-freebsd-net@FreeBSD.ORG Mon Nov 12 08:42:43 2007 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 1ED8C16A417 for ; Mon, 12 Nov 2007 08:42:43 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id CCBA113C4B3 for ; Mon, 12 Nov 2007 08:42:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 323AF46CE7; Mon, 12 Nov 2007 03:27:11 -0500 (EST) Date: Mon, 12 Nov 2007 08:25:45 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ed Mandy In-Reply-To: <008501c823ef$93a26af0$25a8a8c0@ermxp> Message-ID: <20071112081303.C81124@fledge.watson.org> References: <008501c823ef$93a26af0$25a8a8c0@ermxp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: System Freezes When MBufClust Usages Rises X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2007 08:42:43 -0000 On Sat, 10 Nov 2007, Ed Mandy wrote: > If kern.ipc.nmbclusters is set to 25600, the system will hard freeze when > "vmstat -z" shows the number of clusters reaches 25600. If > kern.ipc.nmbclusters is set to 0 (or 102400), the system will hard freeze > when "vmstat -z" shows the number of clusters is around 66000. When it > freezes, the number of Kbytes allocated to network (as shown by "netstat > -m") is roughly 160,000 (160MB). > > For a while, we thought that there may be a limit of 65536 mbuf clusters, so > we tested building the kernel with MCLSHIFT=12, which makes each mbcluster > 4096-bytes. With this configuration, nmbclusters only reached about 33000 > before the system froze. The number of Kbytes allocated to network (as > shown by "netstat -m") still maxed out at around 160,000. > > Now, it seems that we are running into some other memory limitation that > occurs when our network allocation gets close to 160MB. We have tried > tuning paramaters such as KVA_PAGES, vm.kmem_size, vm.kmem_size_max, etc. > Though, we are unsure if the mods we made there helped in any way. > > This is all being done on Celeron 2.8GHz machines with 3+ GB of RAM running > FreeBSD 5.3. We are very much tied to this platform at the moment, and > upgrading is not a realistic option for us. We would like to tune the > systems to not lockup. We can currently work around the problem (by using > smaller buffers and such), but it is at the expense of network throughput, > which is less than ideal. > > Are there any other parameters that would help us to allocate more memory to > the kernel networking? What other options should we look into? I'd like to diagnose "freeze hard" a little more to understand what's going on. Hopefully this won't be too disruptive for your environment while you're doing it. First off, can you tell me how you're accessing the system to run diagnostic tools, monitor it, etc? Remember that if you run out of clusters, you may experience network deadlocks that prevent SSH sessions from operating (since there may be no memory for them to operate), so direct console access may be required to effectively monitor the system when in an extreme state of low memory in the network stack. Could you tell me if you are using a serial console or the video console? (Or firewire, I suppose?) FreeBSD 5.3 was the first release to include an MPSAFE network stack, and there were a number of optionally compiled features that could disable MPSAFE networking, resulting in the Giant lock being held over network operations. Could you tell me what the value of the sysctl debug.mpsafenet is? When the system appears to hard hang, does it recover if, say, left five minutes? What if you unplug the network cable and leave it five minutes? Does the numlock key on the console work? If you leave the console logged in and running an application (such as "sleep 100000") and the system hangs, what do you see if you hit Ctrl-T? If you compile options BREAK_TO_DEBUGGER into the kernel and generate a serial break / hit ctrl-alt-esc, are you able to get into the debugger? If you type in "trace", what do you get? (There is a chapter of the developer's handbook that talks about using the kernel debugger, FYI). With 5.3, we found that usig a serial console to get to the debugger was a lot more reliable than the video console -- this is in part because a significant amount of the kernel (especially file systems and the video console) still run under Giant, so a thread hanging while holding Giant can prevent a console break from getting to the debugger. My advice would be to use a serial console anyway, if possible, when debugging, as it means you can use a second machine to copy and paste DDB output into a file to e-mail out later. After about the third line of a kernel stack trace, copying addresses out by hand becomes pretty painful :-). Unfortunately, I have to say that my first advice would be to upgrade -- not just because a lot of work has been done relating to network stack performance and stability since 5.3, but also because the debugging tools have gotten a lot better since then. For example, in more recent versions the kernel debugging includes memory monitoring tools, commands to more readily extract debugging information, etc. 5.3 is a solid and functional release, but when it comes to debugging problems of this sort, being on a more recent release means you're more likely to see the problem already fixed, and even if not, it will be easier for us to fix it. I understand that may simply not be possible, but if you have that flexibility, it's good advice. A general comment on configuration: increasing the maximum memory allocated to the network stack can indeed increase your KVA usage significantly. You might well find that tuning KVA up is required to run with very high memory configurations for the network stack, so your intuitions about tuning that up aren't bad. However, when you run out of KVA, the result is usually a panic (since the kernel basically has to halt), so if you're not seeing a panic then you're probably not yet hitting the limit. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Mon Nov 12 11:07:02 2007 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 0A5E816A4CE for ; Mon, 12 Nov 2007 11:07:02 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EB58D13C4C5 for ; Mon, 12 Nov 2007 11:07:01 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id lACB71NW089758 for ; Mon, 12 Nov 2007 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id lACB71R3089754 for freebsd-net@FreeBSD.org; Mon, 12 Nov 2007 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 12 Nov 2007 11:07:01 GMT Message-Id: <200711121107.lACB71R3089754@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2007 11:07:02 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/115360 net [ipv6] IPv6 address and if_bridge don't play well toge 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/21998 net [socket] [patch] ident only for outgoing connections a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/109406 net [ndis] Broadcom WLAN driver 4.100.15.5 doesn't work wi o kern/110959 net [ipsec] Filtering incoming packets with enc0 does not o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net IP v4 udp fragmented packet reject o kern/113457 net [ipv6] deadlock occurs if a tunnel goes down while the o kern/113842 net [ipv6] PF_INET6 proto domain state can't be cleared wi o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net 6.2-STABLE panic during use of multi-cast networking c o kern/116172 net Network / ipv6 recursive mutex panic o kern/116185 net if_iwi driver leads system to reboot o kern/116186 net can not set wi channel on current o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net ifconfig tunX destroy: panic o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117293 net [carp] CARP interfaces causes packet loss o kern/117423 net Duplicate IP on different interfaces o bin/117448 net [carp] 6.2 kernel crash 30 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/103253 net inconsistent behaviour in arp reply of a bridge o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/112654 net [pcn] Kernel panic upon if_pcn module load on a Netfin o kern/114095 net [carp] carp+pf delay with high state limit o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] fstat(1): add INET/INET6 socket details as in o bin/117339 net [patch] route(8): loading routing management commands o kern/117456 net [ipv6] ipv6 neighbour discovery / bce multicast probl 17 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Nov 12 15:33:19 2007 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 E4B6B16A421 for ; Mon, 12 Nov 2007 15:33:19 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [IPv6:2001:6f8:1098::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9235F13C4A5 for ; Mon, 12 Nov 2007 15:33:19 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id lACFXJDk029876 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 12 Nov 2007 16:33:19 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id lACFXIAE022358; Mon, 12 Nov 2007 16:33:18 +0100 (MET) Date: Mon, 12 Nov 2007 16:33:18 +0100 From: Daniel Hartmeier To: Max Laier Message-ID: <20071112153318.GE28276@insomnia.benzedrine.cx> References: <86zlxoblmj.fsf@ds4.des.no> <200711082259.46222.max@love2party.net> <86fxzgl63d.fsf@ds4.des.no> <200711090059.54990.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200711090059.54990.max@love2party.net> User-Agent: Mutt/1.5.12-2006-07-14 Cc: Dag-Erling Sm?rgrav , freebsd-net@freebsd.org Subject: Re: pf misfeature X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2007 15:33:20 -0000 On Fri, Nov 09, 2007 at 12:59:46AM +0100, Max Laier wrote: > Daniel, do you spot anything strange with these skip steps (or otherwise)? The problem is the lack of IP reassembly in this configuration. In pf_test_fragment(), a rule with r->flagset ("flags S/SA") is skipped. Generally, stateful filtering _requires_ IP reassembly. As long as no fragmentation occurs, it works even without reassembly. I suspect your UDP NFS traffic is fragmented. Try adding scrub in on $if all fragment reassemble at the top. Daniel From owner-freebsd-net@FreeBSD.ORG Tue Nov 13 03:01:30 2007 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 6491116A468 for ; Tue, 13 Nov 2007 03:01:30 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.freebsd.org (Postfix) with ESMTP id DC12D13C48D for ; Tue, 13 Nov 2007 03:01:29 +0000 (UTC) (envelope-from max@love2party.net) Received: from amd64.laiers.local (dslb-088-066-001-180.pools.arcor-ip.net [88.66.1.180]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1Irm1Q2j2b-0003oU; Tue, 13 Nov 2007 04:01:20 +0100 From: Max Laier Organization: FreeBSD To: Daniel Hartmeier Date: Tue, 13 Nov 2007 04:00:50 +0100 User-Agent: KMail/1.9.7 References: <86zlxoblmj.fsf@ds4.des.no> <200711090059.54990.max@love2party.net> <20071112153318.GE28276@insomnia.benzedrine.cx> In-Reply-To: <20071112153318.GE28276@insomnia.benzedrine.cx> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2348610.Mxk9AcOtoc"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200711130401.02049.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+1DQxcHrqsdF+yyBH/pJO40tuhj5PS/9XAqDV ktw0FTfRUoR7YRqZWZv1qiYFqAQ24/bGl7IPVYOJoZJn9nw0WK 6Oibyjm9s4jcCxQEWGzxy8I/RegHuEYazfHF682s6M= Cc: Dag-Erling Sm?rgrav , freebsd-net@freebsd.org Subject: Re: pf misfeature 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, 13 Nov 2007 03:01:30 -0000 --nextPart2348610.Mxk9AcOtoc Content-Type: multipart/mixed; boundary="Boundary-01=_lNROHOlrXt6f+1l" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_lNROHOlrXt6f+1l Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 12 November 2007, Daniel Hartmeier wrote: > On Fri, Nov 09, 2007 at 12:59:46AM +0100, Max Laier wrote: > > Daniel, do you spot anything strange with these skip steps (or > > otherwise)? > > The problem is the lack of IP reassembly in this configuration. > > In pf_test_fragment(), a rule with r->flagset ("flags S/SA") is > skipped. Ah, I missed that one. Wouldn't it make sense to conditionalize these=20 tests on the protocol? The attached can probably be optimized, but you=20 get the general idea. It seems wrong that an explicit udp-rule behaves differently than an=20 implied one. > Generally, stateful filtering _requires_ IP reassembly. As long as no > fragmentation occurs, it works even without reassembly. I suspect your > UDP NFS traffic is fragmented. > > Try adding > > scrub in on $if all fragment reassemble > > at the top. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-01=_lNROHOlrXt6f+1l Content-Type: text/x-diff; charset="iso-8859-1"; name="pf.cond-frag-check.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pf.cond-frag-check.diff" Index: pf.c =================================================================== RCS file: /home/ncvs/src/sys/contrib/pf/net/pf.c,v retrieving revision 1.50 diff -u -r1.50 pf.c --- pf.c 28 Oct 2007 17:12:46 -0000 1.50 +++ pf.c 13 Nov 2007 02:58:31 -0000 @@ -4560,9 +4560,17 @@ r = r->skip[PF_SKIP_DST_ADDR].ptr; else if (r->tos && !(r->tos == pd->tos)) r = TAILQ_NEXT(r, entries); - else if (r->src.port_op || r->dst.port_op || - r->flagset || r->type || r->code || - r->os_fingerprint != PF_OSFP_ANY) + else if (r->os_fingerprint != PF_OSFP_ANY) + r = TAILQ_NEXT(r, entries); + else if (pd->proto == IPPROTO_UDP && + (r->src.port_op || r->dst.port_op)) + r = TAILQ_NEXT(r, entries); + else if (pd->proto == IPPROTO_TCP && + (r->src.port_op || r->dst.port_op || r->flagset)) + r = TAILQ_NEXT(r, entries); + else if ((pd->proto == IPPROTO_ICMP || + pd->proto == IPPROTO_ICMPV6) && + (r->type || r->code)) r = TAILQ_NEXT(r, entries); else if (r->prob && r->prob <= arc4random()) r = TAILQ_NEXT(r, entries); --Boundary-01=_lNROHOlrXt6f+1l-- --nextPart2348610.Mxk9AcOtoc Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHORNtXyyEoT62BG0RAq16AJ4zL3a+iKwElpx1jDcwKh8xRTmxRQCfaNKZ GXIhVM7cB44USWAY7raKz9w= =2qg3 -----END PGP SIGNATURE----- --nextPart2348610.Mxk9AcOtoc-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 15 01:12:37 2007 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 96EFD16A418 for ; Thu, 15 Nov 2007 01:12:37 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id 1619D13C43E for ; Thu, 15 Nov 2007 01:12:36 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so331248nfb for ; Wed, 14 Nov 2007 17:12:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=ly+Hz7gKKdZmk/Z73Auc20zpV2dPhnnc2RoI2XuUeJE=; b=WC3kR/ZmxFopJmzpkQQZZXRcsRtymi9RtCPbGnsnda4a8xv0a6IyJKKD06B/dmFyLsKPHeTjpl78ct0a+S9bhb+d3v7QB7Gc3VK90QW/BJ6Q5q4pk53dPDHyONgI6pRU5RIsgvHF7IT5ZNARd7zyXBfpPVhrsQ9fDCKKjY4QxlY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bki8dnyVWnWotig5kY4uW6eOdf9CQye+hgGVKOady51AhQWHSuMsMmI9Z+Dr52u0/NpeOiczFbAQ9n06imtFW/Cmmhb8b7lU2QJs1I7/XihEnc9g7jV7BfJ+czepkMZM5rVrnO9Vkr6Li25oD/brwDWRoGBfXApf7NTcP8DxbZY= Received: by 10.86.100.7 with SMTP id x7mr86689fgb.1195089155184; Wed, 14 Nov 2007 17:12:35 -0800 (PST) Received: by 10.86.100.19 with HTTP; Wed, 14 Nov 2007 17:12:35 -0800 (PST) Message-ID: <2a41acea0711141712x533bcdbex92df05280311be8e@mail.gmail.com> Date: Wed, 14 Nov 2007 17:12:35 -0800 From: "Jack Vogel" To: "Wilkinson, Alex" In-Reply-To: <1B860D81B4F3F44398B9AE84D91C151671D11B@stlex510.dsto.defence.gov.au> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1B860D81B4F3F44398B9AE84D91C151671D11B@stlex510.dsto.defence.gov.au> Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: I/OAT ... Coming Soon ? 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, 15 Nov 2007 01:12:37 -0000 On Nov 14, 2007 5:01 PM, Wilkinson, Alex wrote: > > Hi all, > > Curious, is I/OAT [http://www.intel.com/go/ioat/] coming to FreeBSD soon > ? LOL, I did a driver for the first version of I/OAT more than a year ago, submitted it and interest was half hearted. The driver needs updating and polishing yet, but interest being what it was it hasn't been a real high priority. Jack From owner-freebsd-net@FreeBSD.ORG Thu Nov 15 01:16:32 2007 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 519AF16A468 for ; Thu, 15 Nov 2007 01:16:32 +0000 (UTC) (envelope-from Alex.Wilkinson@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id D671A13C45A for ; Thu, 15 Nov 2007 01:16:31 +0000 (UTC) (envelope-from Alex.Wilkinson@dsto.defence.gov.au) Received: from ednmsw511.dsto.defence.gov.au (ednmsw511.dsto.defence.gov.au [131.185.68.12]) by digger1.defence.gov.au (8.13.8/8.13.8) with ESMTP id lAF10ttP005270; Thu, 15 Nov 2007 11:30:55 +1030 (CST) Received: from fmbex510.dsto.defence.gov.au (fmbex510.dsto.defence.gov.au) by ednmsw511.dsto.defence.gov.au (Clearswift SMTPRS 5.2.9) with ESMTP id ; Thu, 15 Nov 2007 11:31:11 +1030 Received: from stlex510.dsto.defence.gov.au ([203.6.60.184]) by fmbex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 12:01:10 +1100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Nov 2007 09:01:09 +0800 Message-ID: <1B860D81B4F3F44398B9AE84D91C151671D11B@stlex510.dsto.defence.gov.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Sec:uI/OAT ... Coming Soon ? Thread-Index: AcgnIwIqhJfMRP1SQBmbF24SRTCh8w== From: "Wilkinson, Alex" To: X-OriginalArrivalTime: 15 Nov 2007 01:01:10.0910 (UTC) FILETIME=[0314E9E0:01C82723] X-TM-AS-Product-Ver: SMEX-7.0.0.1526-5.0.1023-15544.003 X-TM-AS-Result: No--1.036400-0.000000-31 Cc: freebsd-net@freebsd.org Subject: I/OAT ... Coming Soon ? 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, 15 Nov 2007 01:16:32 -0000 Hi all, Curious, is I/OAT [http://www.intel.com/go/ioat/] coming to FreeBSD soon ? Seems to be in the works for Linux [http://www.linux-foundation.org/en/Net:I/OAT] and OpenSolaris [http://blogs.sun.com/markusflierl/entry/what_s_going_on_in]. -aW IMPORTANT: This email remains the property of the Australian Defence Organi= sation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1= 914. If you have received this email in error, you are requested to contac= t the sender and delete the email. From owner-freebsd-net@FreeBSD.ORG Thu Nov 15 01:52:20 2007 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 16BC416A46D for ; Thu, 15 Nov 2007 01:52:18 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outV.internet-mail-service.net (outV.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id C5B0F13C43E for ; Thu, 15 Nov 2007 01:52:18 +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; Wed, 14 Nov 2007 17:52:17 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id DE2FF126A11; Wed, 14 Nov 2007 17:52:16 -0800 (PST) Message-ID: <473BA656.7020508@elischer.org> Date: Wed, 14 Nov 2007 17:52:22 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Jack Vogel References: <1B860D81B4F3F44398B9AE84D91C151671D11B@stlex510.dsto.defence.gov.au> <2a41acea0711141712x533bcdbex92df05280311be8e@mail.gmail.com> In-Reply-To: <2a41acea0711141712x533bcdbex92df05280311be8e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, "Wilkinson, Alex" Subject: Re: I/OAT ... Coming Soon ? 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, 15 Nov 2007 01:52:20 -0000 Jack Vogel wrote: > On Nov 14, 2007 5:01 PM, Wilkinson, Alex > wrote: >> Hi all, >> >> Curious, is I/OAT [http://www.intel.com/go/ioat/] coming to FreeBSD soon >> ? > > LOL, I did a driver for the first version of I/OAT more than a year > ago, submitted > it and interest was half hearted. > > The driver needs updating and polishing yet, but interest being what it was > it hasn't been a real high priority. > I saw what I thought you called a "preliminary" driver. There was discussion and I thought you got positive but muted (along the lines of "nice.. when will there be hardware for it?") and some discussion of how it fits in with TCP offload, but I don't think that anyone said they didn't like the idea.. hmm didn't someone else have an implementation? or am I getting my wires crossed on that? > Jack > _______________________________________________ > 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 Thu Nov 15 06:21:42 2007 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 636D316A417 for ; Thu, 15 Nov 2007 06:21:42 +0000 (UTC) (envelope-from kevin@bortis.ch) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.189]) by mx1.freebsd.org (Postfix) with ESMTP id 467B113C478 for ; Thu, 15 Nov 2007 06:21:41 +0000 (UTC) (envelope-from kevin@bortis.ch) Received: by rv-out-0910.google.com with SMTP id l15so404104rvb for ; Wed, 14 Nov 2007 22:21:41 -0800 (PST) Received: by 10.141.162.16 with SMTP id p16mr146444rvo.1195107701356; Wed, 14 Nov 2007 22:21:41 -0800 (PST) Received: by 10.141.116.14 with HTTP; Wed, 14 Nov 2007 22:21:41 -0800 (PST) Message-ID: Date: Thu, 15 Nov 2007 07:21:41 +0100 From: "Kevin Bortis" Sender: kevin@bortis.ch To: freebsd-net@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <471E7C91.9050403@FreeBSD.org> <471EA800.5050105@ibctech.ca> <200710240736.l9O7a5PI003244@post.frank-behrens.de> X-Google-Sender-Auth: 0440ab73d18ff2ad Subject: Re: dualstack IPv4/IPv6 ADSL PPPoE configuration? 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, 15 Nov 2007 06:21:42 -0000 I tried ppp with autoconf IPv6, but without success. Now I test FreeBSD 7 Beta2 and mpd5 from the ports collection. If I run /usr/local/sbin/mpd5, there is a line: [L1] rec'd unexpected protocol IPV6CP, rejecting So here is my question: Is the provider rejecting the IPV6CP package or is this rejecting local. I searched in the mpd5 manuals, but there is not much written about IPv6. Regards Kevin PS: If someone knows a source for mpd5 manuals and docs, please post. I tried to get answers in the mpd-user mailinglist, but I think I am the only user :-) logs and config : #################### #log ... [L1] AUTH: Accounting-Thread finished normally [B1] IPCP: rec'd Configure Request #1 (Req-Sent) COMPPROTO VJCOMP, 16 comp. channels, allow comp-cid IPADDR 212.xx.xx.xx 212.xx.xx.xx is OK [B1] IPCP: SendConfigAck #1 COMPPROTO VJCOMP, 16 comp. channels, allow comp-cid IPADDR 212.xx.xx.xx [B1] IPCP: state change Req-Sent --> Ack-Sent [L1] rec'd unexpected protocol IPV6CP, rejecting [B1] IPCP: rec'd Configure Nak #1 (Ack-Sent) IPADDR 212.xx.yy.yy 212.xx.yy.yy is OK [B1] IPCP: SendConfigReq #2 ... [B1] IPCP: LayerUp 212.xx.yy.yy -> 212.xx.xx.xx [B1] IFACE: Up event ... ############# #mpd.config: default: load provider provider: create bundle static B1 set iface route default set ipcp ranges 0.0.0.0/0 0.0.0.0/0 set ipv6cp enable create link static L1 pppoe set link action bundle B1 set auth authname "myUsername@myProvider.xx" set auth password "myPassword" set link max-redial 0 set link mtu 1460 set link keep-alive 10 60 set pppoe iface le0 set pppoe service "" open From owner-freebsd-net@FreeBSD.ORG Thu Nov 15 08:58:46 2007 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 7C35816A41B for ; Thu, 15 Nov 2007 08:58:46 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 11F3813C46E for ; Thu, 15 Nov 2007 08:58:45 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so404149nfb for ; Thu, 15 Nov 2007 00:58:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=F8j7iHyZz07srDStEEd/67bYI1zTIKnYOIhCVXCHvKY=; b=JiK5D4KaSTyqBcHRW4HQrlXc9wSJigEYgXLiOdTS0IEKW9LWppMCX1P6NCk0Rf4Q7LKFAd6EL5zsdhfSL+f3mtv5md2Ad794mlaAGY/0Ll+pceHOj7YbXDQzgAxK3okysSaUDWSoeNe/j0qMpFxNS2NkazYVzuihfnBNv78vA68= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QHzrhU+JWTDPvueZmd4t7VWuyzrBvRp8MSB9YM1HpJMPAiYcHTwz4iXH4BBQuUmzMYKZfwAWnOOAv0Oef4JJUGXhLEWTB3vBu9noneuDpMIkDlRfWtJZDqVH9GxdBzNLBJu5mcNs8pyesug441q5ha+Ad7FBIXCkThylq00Mqrg= Received: by 10.86.100.7 with SMTP id x7mr421450fgb.1195117124237; Thu, 15 Nov 2007 00:58:44 -0800 (PST) Received: by 10.86.100.19 with HTTP; Thu, 15 Nov 2007 00:58:44 -0800 (PST) Message-ID: <2a41acea0711150058v5eaa2866v40eb0c0bc65b4ede@mail.gmail.com> Date: Thu, 15 Nov 2007 00:58:44 -0800 From: "Jack Vogel" To: "Julian Elischer" In-Reply-To: <473BA656.7020508@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1B860D81B4F3F44398B9AE84D91C151671D11B@stlex510.dsto.defence.gov.au> <2a41acea0711141712x533bcdbex92df05280311be8e@mail.gmail.com> <473BA656.7020508@elischer.org> Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, "Wilkinson, Alex" Subject: Re: I/OAT ... Coming Soon ? 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, 15 Nov 2007 08:58:46 -0000 On Nov 14, 2007 5:52 PM, Julian Elischer wrote: > > Jack Vogel wrote: > > On Nov 14, 2007 5:01 PM, Wilkinson, Alex > > wrote: > >> Hi all, > >> > >> Curious, is I/OAT [http://www.intel.com/go/ioat/] coming to FreeBSD soon > >> ? > > > > LOL, I did a driver for the first version of I/OAT more than a year > > ago, submitted > > it and interest was half hearted. > > > > The driver needs updating and polishing yet, but interest being what it was > > it hasn't been a real high priority. > > > > I saw what I thought you called a "preliminary" driver. > There was discussion and I thought you got positive but > muted (along the lines of "nice.. when will there be hardware for it?") > and some discussion of how it fits in with TCP offload, but I don't think > that anyone said they didn't like the idea.. > > hmm didn't someone else have an implementation? or am I getting > my wires crossed on that? You are probably right, its been quite a while, and there were other factors that have effected my perception. The driver just for the engine didn't require the stack portion that Prafulla did, although we need something using the thing :) Not sure what other implementation you are thinking of. Linux has it of course. I'd be glad to resurrect the code and get on with it in any case. Jack From owner-freebsd-net@FreeBSD.ORG Thu Nov 15 10:54:53 2007 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 A24EC16A469 for ; Thu, 15 Nov 2007 10:54:53 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 21DF313C457 for ; Thu, 15 Nov 2007 10:54:52 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona 1.7.0 Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 45731700; Thu, 15 Nov 2007 11:44:51 +0200 Message-ID: <473C1512.5000101@mavhome.dp.ua> Date: Thu, 15 Nov 2007 11:44:50 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.0 (X11/20070424) MIME-Version: 1.0 To: Kevin Bortis References: <471E7C91.9050403@FreeBSD.org> <471EA800.5050105@ibctech.ca> <200710240736.l9O7a5PI003244@post.frank-behrens.de> <1195118600.00828881.1195108201@10.7.7.3> In-Reply-To: <1195118600.00828881.1195108201@10.7.7.3> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: dualstack IPv4/IPv6 ADSL PPPoE configuration? 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, 15 Nov 2007 10:54:53 -0000 Kevin Bortis wrote: > I tried ppp with autoconf IPv6, but without success. Now I test > FreeBSD 7 Beta2 and mpd5 from the ports collection. > > If I run /usr/local/sbin/mpd5, there is a line: [L1] rec'd unexpected > protocol IPV6CP, rejecting > > So here is my question: Is the provider rejecting the IPV6CP package > or is this rejecting local. It is you. > I searched in the mpd5 manuals, but there is not much written about IPv6. It's just because there is nothing to say. There are very few configuration options for ipv6. > Regards Kevin > > PS: If someone knows a source for mpd5 manuals and docs, please post. > I tried to get answers in the mpd-user mailinglist, but I think I am > the only user :-) Latest manuals is here: http://mpd.sourceforge.net/doc5/mpd.html Also mpd installs manuals in /usr/local/share/... directory. Mailinglist is almost dead due to huge amount of spam there. Use mpd project forum at sourceforge. > ############# > #mpd.config: > > set ipv6cp enable This command is incorrect. You should see error messages about this in logs. This command should be pronounced as 'set bundle enable ipv6cp'. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Thu Nov 15 14:46:52 2007 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 6317216A418 for ; Thu, 15 Nov 2007 14:46:52 +0000 (UTC) (envelope-from brian@tnetus.com) Received: from k2smtpout05-02.prod.mesa1.secureserver.net (k2smtpout05-02.prod.mesa1.secureserver.net [64.202.189.57]) by mx1.freebsd.org (Postfix) with SMTP id 28C8813C45A for ; Thu, 15 Nov 2007 14:46:51 +0000 (UTC) (envelope-from brian@tnetus.com) Received: (qmail 4434 invoked from network); 15 Nov 2007 14:20:10 -0000 Received: from unknown (HELO tnetus.com) (68.178.207.93) by k2smtpout05-02.prod.mesa1.secureserver.net (64.202.189.57) with SMTP; 15 Nov 2007 14:20:10 -0000 Received: from [10.1.1.134] ([85.97.4.79]) by tnetus.com with hMailServer ; Thu, 15 Nov 2007 09:20:12 -0500 Message-ID: <473C5593.4080407@tnetus.com> Date: Thu, 15 Nov 2007 16:20:03 +0200 From: Brian Hawk User-Agent: Thunderbird 2.0.0.7pre (Windows/20071019) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-9; format=flowed Content-Transfer-Encoding: 7bit Subject: Interface address sourced packets go thru default gateway on another interface 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, 15 Nov 2007 14:46:52 -0000 Hi ppl, Sorry for the bizarre subject but I really didn't know how to put this on. I have 3 interfaces: xl0, xl1 and rl0. rl0 is the where ppp daemon (for ADSL) runs on, so I also have tun0 which grabs the default gateway. My problem is with xl1 which is connected to a leased-line and has a static external IP, let's say A.B.C.D. My problem is, packets generated with A.B.C.D source address does not go out thru xl1 but tun0 (which is the default gw). The problem also happens when an outsite packet destined for A.B.C.D arrives. The packet correctly arrives from xl1 interface but the response goes out from tun0. This is driving me crazy since it shouldn't really happen and it used not to happen. Everything was working fine until I don't know when and why, now I cannot send any packets out thru my xl1 interface by binding its source address to the packets. Anyone has a clue why this might be happening? -Brian From owner-freebsd-net@FreeBSD.ORG Thu Nov 15 16:01:31 2007 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 7ABD416A417 for ; Thu, 15 Nov 2007 16:01:31 +0000 (UTC) (envelope-from iaccounts@ibctech.ca) Received: from pearl.ibctech.ca (pearl.ibctech.ca [208.70.104.210]) by mx1.freebsd.org (Postfix) with ESMTP id 1115513C43E for ; Thu, 15 Nov 2007 16:01:30 +0000 (UTC) (envelope-from iaccounts@ibctech.ca) Received: (qmail 21675 invoked by uid 1002); 15 Nov 2007 16:01:30 -0000 Received: from iaccounts@ibctech.ca by pearl.ibctech.ca by uid 89 with qmail-scanner-1.22 (spamassassin: 2.64. Clear:RC:1(208.70.104.100):. Processed in 8.996955 secs); 15 Nov 2007 16:01:30 -0000 Received: from unknown (HELO ?192.168.30.110?) (steve@ibctech.ca@208.70.104.100) by pearl.ibctech.ca with (DHE-RSA-AES256-SHA encrypted) SMTP; 15 Nov 2007 16:01:21 -0000 Message-ID: <473C6D51.6070500@ibctech.ca> Date: Thu, 15 Nov 2007 11:01:21 -0500 From: Steve Bertrand User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Hawk References: <473C5593.4080407@tnetus.com> In-Reply-To: <473C5593.4080407@tnetus.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Interface address sourced packets go thru default gateway on another interface 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, 15 Nov 2007 16:01:31 -0000 > My problem is, packets generated with A.B.C.D source address does not go > out thru xl1 but tun0 (which is the default gw). The problem also > happens when an outsite packet destined for A.B.C.D arrives. The packet > correctly arrives from xl1 interface but the response goes out from > tun0. This is driving me crazy since it shouldn't really happen and it > used not to happen. Everything was working fine until I don't know when > and why, now I cannot send any packets out thru my xl1 interface by > binding its source address to the packets. Show the output to: # netstat -rn ...are you *sure* that it hasn't always worked this way? Steve From owner-freebsd-net@FreeBSD.ORG Thu Nov 15 17:09:41 2007 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 AF0A116A469; Thu, 15 Nov 2007 17:09:41 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id 1E41213C457; Thu, 15 Nov 2007 17:09:40 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 15 Nov 2007 08:34:12 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.14.1/8.12.11) with ESMTP id lAFGeE7O021480; Thu, 15 Nov 2007 08:40:14 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.1/8.13.1/Submit) id lAFGeCto021475; Thu, 15 Nov 2007 08:40:12 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200711151640.lAFGeCto021475@ambrisko.com> In-Reply-To: <473BA656.7020508@elischer.org> To: Julian Elischer Date: Thu, 15 Nov 2007 08:40:12 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Jack Vogel , "Wilkinson, Alex" Subject: Re: I/OAT ... Coming Soon ? 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, 15 Nov 2007 17:09:41 -0000 Julian Elischer writes: | Jack Vogel wrote: | > On Nov 14, 2007 5:01 PM, Wilkinson, Alex | > wrote: | >> Hi all, | >> | >> Curious, is I/OAT [http://www.intel.com/go/ioat/] coming to FreeBSD soon | >> ? | > | > LOL, I did a driver for the first version of I/OAT more than a year | > ago, submitted | > it and interest was half hearted. | > | > The driver needs updating and polishing yet, but interest being what it was | > it hasn't been a real high priority. | | I saw what I thought you called a "preliminary" driver. | There was discussion and I thought you got positive but | muted (along the lines of "nice.. when will there be hardware for it?") | and some discussion of how it fits in with TCP offload, but I don't think | that anyone said they didn't like the idea.. FWIW, several of us should have motherboards that support it now. For example the Dell PE29XX/PE1950 line now has support if you upgrade old machines to a newer BIOS and then turn it on in the BIOS setup. I'm not sure what em(4) cards support it. So I think hardware should be available now. At the time the PE29XX family BIOS did not support it :-( Doug A. From owner-freebsd-net@FreeBSD.ORG Thu Nov 15 17:30:14 2007 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 1EEEF16A417; Thu, 15 Nov 2007 17:30:14 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id 0764913C461; Thu, 15 Nov 2007 17:30:12 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 15 Nov 2007 09:23:34 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.14.1/8.12.11) with ESMTP id lAFHTbMj024352; Thu, 15 Nov 2007 09:29:37 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.1/8.13.1/Submit) id lAFHTbiq024351; Thu, 15 Nov 2007 09:29:37 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200711151729.lAFHTbiq024351@ambrisko.com> In-Reply-To: To: Scott Ullrich Date: Thu, 15 Nov 2007 09:29:37 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Julian Elischer , "Wilkinson, Alex" , Jack Vogel Subject: Re: I/OAT ... Coming Soon ? 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, 15 Nov 2007 17:30:14 -0000 Scott Ullrich writes: [ Charset ISO-8859-1 unsupported, converting... ] | On 11/15/07, Doug Ambrisko wrote: | > FWIW, several of us should have motherboards that support it now. | > For example the Dell PE29XX/PE1950 line now has support if you upgrade | > old machines to a newer BIOS and then turn it on in the BIOS setup. | > I'm not sure what em(4) cards support it. So I think hardware should | > be available now. At the time the PE29XX family BIOS did not support it | | I have a stack of Dell 2970's with Intel 1000 cards and will be happy | to test this when a patch is available. Thanks for working on this | Jack! Hmm, I forgot about the 2970 which are AMD based. Can you check the BIOS to see if there is an option to turn it on? I think this is an Intel feature. AMD might have something close? We have one 2970 that we've played with a little but not much. I can't say for sure if it has it. Doug A. From owner-freebsd-net@FreeBSD.ORG Thu Nov 15 17:39:57 2007 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 538BA16A4DF for ; Thu, 15 Nov 2007 17:39:57 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id 1D47913C447 for ; Thu, 15 Nov 2007 17:39:57 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so751298waf for ; Thu, 15 Nov 2007 09:39:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=n5lfmyMqiwYM6yF9nAD5H1TwadvHgQAY0vqczIcKlJQ=; b=AlFHGNdlrITgLCP9e9jsijueTA/iy82dZnLygrL1XJATyPMGcGCxfzbyFXUj8aAszJHPqkmKxNiM1O0D0Zb1F37hLw0X6yLlgRq9+LChMFJcw8MAi8cvkEmB9vwdms4aKDpJcRaMhNobXc/7tefhVwgHhHMQ0owMytG+dOzV7c4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MDGwI2rs6bm9HxwpW/dHc3AGxOsK6QX+uiodWiUTLqRsXEUAaZZbGjr6NVevppYdjD3OI+3D+ZoY52KOQRrFNeCS+dt9zLPu90KZ6cArKd99H5Y8LXGyO1K5ggmL+vgvAXMy1WZqDp4pCqhZkFyHDAACeZwQ3kKjFQlFcQVMIj4= Received: by 10.114.89.1 with SMTP id m1mr925673wab.1195146823316; Thu, 15 Nov 2007 09:13:43 -0800 (PST) Received: by 10.115.109.10 with HTTP; Thu, 15 Nov 2007 09:13:43 -0800 (PST) Message-ID: Date: Thu, 15 Nov 2007 12:13:43 -0500 From: "Scott Ullrich" To: "Doug Ambrisko" In-Reply-To: <200711151640.lAFGeCto021475@ambrisko.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <473BA656.7020508@elischer.org> <200711151640.lAFGeCto021475@ambrisko.com> Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Julian Elischer , "Wilkinson, Alex" , Jack Vogel Subject: Re: I/OAT ... Coming Soon ? 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, 15 Nov 2007 17:39:57 -0000 On 11/15/07, Doug Ambrisko wrote: > FWIW, several of us should have motherboards that support it now. > For example the Dell PE29XX/PE1950 line now has support if you upgrade > old machines to a newer BIOS and then turn it on in the BIOS setup. > I'm not sure what em(4) cards support it. So I think hardware should > be available now. At the time the PE29XX family BIOS did not support it I have a stack of Dell 2970's with Intel 1000 cards and will be happy to test this when a patch is available. Thanks for working on this Jack! Scott From owner-freebsd-net@FreeBSD.ORG Thu Nov 15 17:52:19 2007 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 C4A4C16A417 for ; Thu, 15 Nov 2007 17:52:19 +0000 (UTC) (envelope-from sullrich@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 7CFE413C447 for ; Thu, 15 Nov 2007 17:52:19 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so547510nzf for ; Thu, 15 Nov 2007 09:52:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=37OMIlnDOVtli05pYPl16l1zHH4MGpnqgpdJhrCZfoc=; b=tCez5h5Wpl8Hq3D6vBJYPR2maczbZqzPJHPIovVG0Bm0+yxcdu/cua4pmzTw5JngHRbJ4eac/FUGTaKJdEMOk6pnlhNNdEK4+u0UylquKoBeHwCRJx7yo94k/b8jXxLSRI4yV1aPGQX6ANFdyjgkNwS789W17GM3VjhRJTyMG9M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jXHvNkZArjQ4Fdr+FakTwN2QBzTzgG2txr5Ky0iRkTBc4G8tvCcPqyUHcP1D6RN+GcTorHZhAv5ow5JnoQGzpcdodjdPNVXnhHD903O/lZumGv5lUm/k3wY4teUoawQpToEM8gW5ff+Ywzjhh8yk6OYXTF92IlbjU7qx1t9aiow= Received: by 10.115.23.12 with SMTP id a12mr155020waj.1195149137463; Thu, 15 Nov 2007 09:52:17 -0800 (PST) Received: by 10.115.109.10 with HTTP; Thu, 15 Nov 2007 09:52:17 -0800 (PST) Message-ID: Date: Thu, 15 Nov 2007 12:52:17 -0500 From: "Scott Ullrich" To: "Doug Ambrisko" In-Reply-To: <200711151729.lAFHTbiq024351@ambrisko.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200711151729.lAFHTbiq024351@ambrisko.com> Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Julian Elischer , "Wilkinson, Alex" , Jack Vogel Subject: Re: I/OAT ... Coming Soon ? 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, 15 Nov 2007 17:52:19 -0000 On 11/15/07, Doug Ambrisko wrote: > Hmm, I forgot about the 2970 which are AMD based. Can you check the > BIOS to see if there is an option to turn it on? I think this is an > Intel feature. AMD might have something close? We have one 2970 > that we've played with a little but not much. I can't say for sure > if it has it. Right you are. As of BIOS 1.2.2 I do not see a I/OAT option. Guess I will need to pick up a different server as we are interested in what kind of packet forwarding rate increase that this feature might bring on a heavily loaded firewall. Scott From owner-freebsd-net@FreeBSD.ORG Thu Nov 15 17:59:43 2007 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 3089C16A419 for ; Thu, 15 Nov 2007 17:59:43 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.189]) by mx1.freebsd.org (Postfix) with ESMTP id A6C8D13C4D1 for ; Thu, 15 Nov 2007 17:59:42 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by mu-out-0910.google.com with SMTP id i10so734015mue for ; Thu, 15 Nov 2007 09:59:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=m97LhbfCrfX1+RdmhhryzxRVLcCqi336Wc/MmpwJeIA=; b=d6XRv/iHRPIP6n9TtZjpuDrmsvJcpuw56tKln/Oi7lvznGQ08xt9ZsLZzzjlB5VcVqln++0s1kGXEx1S2HUOohT2tUa7fUWhNgRm4QbQpG4Ha7CF4TEKkZQOsXkjepsZ9ENwwcWNoqirgIqxaxhyh6hw5om/xFphNUF+kVBSbT4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Y2X/MgEGeoxgqQmqODMmlUXdf887Y/pYHokYrGJRGAaB+yjb9vhZYzU8ck8Ixg2S4MuDi36UuJLmVexU7mSDc/IZuWOXX/aIsXoGwWrIlUvFuT9JF3wuaoinkhTMJUKsYOz5Yb98l0bEgW5TzqGTCn/3XmfpwR2aKZncQzLoA5E= Received: by 10.86.99.9 with SMTP id w9mr852436fgb.1195149579732; Thu, 15 Nov 2007 09:59:39 -0800 (PST) Received: by 10.86.100.19 with HTTP; Thu, 15 Nov 2007 09:59:39 -0800 (PST) Message-ID: <2a41acea0711150959h8d5e0d2ta5c1f2551a2ce22b@mail.gmail.com> Date: Thu, 15 Nov 2007 09:59:39 -0800 From: "Jack Vogel" To: "Scott Ullrich" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200711151729.lAFHTbiq024351@ambrisko.com> Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Julian Elischer , "Wilkinson, Alex" Subject: Re: I/OAT ... Coming Soon ? 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, 15 Nov 2007 17:59:43 -0000 On Nov 15, 2007 9:52 AM, Scott Ullrich wrote: > On 11/15/07, Doug Ambrisko wrote: > > Hmm, I forgot about the 2970 which are AMD based. Can you check the > > BIOS to see if there is an option to turn it on? I think this is an > > Intel feature. AMD might have something close? We have one 2970 > > that we've played with a little but not much. I can't say for sure > > if it has it. > > Right you are. As of BIOS 1.2.2 I do not see a I/OAT option. Guess > I will need to pick up a different server as we are interested in what > kind of packet forwarding rate increase that this feature might bring > on a heavily loaded firewall. Its IN the chipset, so if its AMD based you won't have it :) Jack From owner-freebsd-net@FreeBSD.ORG Thu Nov 15 18:01:43 2007 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 E43C716A417 for ; Thu, 15 Nov 2007 18:01:43 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id B3FFC13C465 for ; Thu, 15 Nov 2007 18:01:43 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so759607waf for ; Thu, 15 Nov 2007 10:01:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=ntyFpcI2J7FTu75UzFf/cEl7QqvcdtN0IbyjIN+6wF4=; b=BBJVtd71Z5R43oUAeubxTdLDQrKsGG8FX1gk0/eP8TNKZnTXCFfx3eseOvrgtMb9xC5/B1KTqfrI2hqiaPuLgLRKl+6ywLqG3ugeb3uRBG5ehMkNUXPX7aWrefwqwy/tx662bgeIy2rrDUeLkYPy3cbR44+hAG0oWEjz7/QdF2c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ffzMwvWNxh1gbxq6y0nmkmkDtyBQqNw9T9iLO/5bv5vslQtkb48iShz3MvTlsWSfFyPM3iwMyVDmllkjsbzf6huBo7BKsMuX2gm3kXIwc0HMTiA6GfUeDfJk9HoKP0gKE3JHGvVcW+7d58tnmKDqEGn+j3v/bA0SVmqgiNGjems= Received: by 10.114.38.2 with SMTP id l2mr180538wal.1195149703381; Thu, 15 Nov 2007 10:01:43 -0800 (PST) Received: by 10.115.109.10 with HTTP; Thu, 15 Nov 2007 10:01:43 -0800 (PST) Message-ID: Date: Thu, 15 Nov 2007 13:01:43 -0500 From: "Scott Ullrich" To: "Jack Vogel" In-Reply-To: <2a41acea0711150959h8d5e0d2ta5c1f2551a2ce22b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200711151729.lAFHTbiq024351@ambrisko.com> <2a41acea0711150959h8d5e0d2ta5c1f2551a2ce22b@mail.gmail.com> Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Julian Elischer , "Wilkinson, Alex" Subject: Re: I/OAT ... Coming Soon ? 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, 15 Nov 2007 18:01:44 -0000 On 11/15/07, Jack Vogel wrote: > Its IN the chipset, so if its AMD based you won't have it :) Thanks for the clarification. I'll be sure to buy all Intel parts on the next server :) Scott From owner-freebsd-net@FreeBSD.ORG Thu Nov 15 22:46:34 2007 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 86E9716A418; Thu, 15 Nov 2007 22:46:34 +0000 (UTC) (envelope-from kmacy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5B2A713C457; Thu, 15 Nov 2007 22:46:34 +0000 (UTC) (envelope-from kmacy@FreeBSD.org) Received: from freefall.freebsd.org (kmacy@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id lAFMkYQ9042296; Thu, 15 Nov 2007 22:46:34 GMT (envelope-from kmacy@freefall.freebsd.org) Received: (from kmacy@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id lAFMkY3T042292; Thu, 15 Nov 2007 22:46:34 GMT (envelope-from kmacy) Date: Thu, 15 Nov 2007 22:46:34 GMT Message-Id: <200711152246.lAFMkY3T042292@freefall.freebsd.org> To: kmacy@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org From: kmacy@FreeBSD.org Cc: Subject: Re: kern/117293: [carp] CARP interfaces causes packet loss 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, 15 Nov 2007 22:46:34 -0000 Synopsis: [carp] CARP interfaces causes packet loss Responsible-Changed-From-To: freebsd-net->glebius Responsible-Changed-By: kmacy Responsible-Changed-When: Thu Nov 15 22:46:04 UTC 2007 Responsible-Changed-Why: glebius is the current acting maintainer for carp http://www.freebsd.org/cgi/query-pr.cgi?pr=117293 From owner-freebsd-net@FreeBSD.ORG Thu Nov 15 22:57:39 2007 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 3C9BC16A418; Thu, 15 Nov 2007 22:57:39 +0000 (UTC) (envelope-from kmacy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 159DB13C502; Thu, 15 Nov 2007 22:57:39 +0000 (UTC) (envelope-from kmacy@FreeBSD.org) Received: from freefall.freebsd.org (kmacy@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id lAFMvcA1042748; Thu, 15 Nov 2007 22:57:38 GMT (envelope-from kmacy@freefall.freebsd.org) Received: (from kmacy@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id lAFMvcrB042744; Thu, 15 Nov 2007 22:57:38 GMT (envelope-from kmacy) Date: Thu, 15 Nov 2007 22:57:38 GMT Message-Id: <200711152257.lAFMvcrB042744@freefall.freebsd.org> To: kmacy@FreeBSD.org, freebsd-net@FreeBSD.org, pf@FreeBSD.org From: kmacy@FreeBSD.org Cc: Subject: Re: kern/114095: [carp] carp+pf delay with high state limit 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, 15 Nov 2007 22:57:39 -0000 Synopsis: [carp] carp+pf delay with high state limit Responsible-Changed-From-To: freebsd-net->pf Responsible-Changed-By: kmacy Responsible-Changed-When: Thu Nov 15 22:56:24 UTC 2007 Responsible-Changed-Why: not clear that this is actually a bug with the state limit set that high http://www.freebsd.org/cgi/query-pr.cgi?pr=114095 From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 00:09:07 2007 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 3283216A41B for ; Fri, 16 Nov 2007 00:09:07 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.186]) by mx1.freebsd.org (Postfix) with ESMTP id AB73113C4DD for ; Fri, 16 Nov 2007 00:09:04 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by mu-out-0910.google.com with SMTP id i10so863033mue for ; Thu, 15 Nov 2007 16:09:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=yH9WEUzivArySiA3Vr4NpSPH9xGRrXl3umMOfPCV71c=; b=SdFS4RFZeBfEfxUEolcZC5eNzGanBthNxKZXliHBj5bshjJZWlQxPXxlf4I7iWiKhVwAPDEB13RPLNkacJ57bLfXIM2/uU4G0R/aajMxwa51G0MZOJ+jN6qRoI/hU5QQuOmZRiAhJgA/Cuh/ChxAZX3LsjAeCL5TEI603CIRxRk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hGS4P7OypkpvKYSmg5fyUPknw2GGcZgLWXueeIBsD0ZamBQf8OF83Un2gOFNVj1YPOAV+SwPPcl7noDu7qU4AJX7qSVO/sCzqnLySEEn6oBy3wt72K56pbd5VKtSH+CS1fx9UagvroBTMFFQOgZkhRMVT1x81uTzXH1S5yA2KqA= Received: by 10.86.91.12 with SMTP id o12mr1156522fgb.1195171742920; Thu, 15 Nov 2007 16:09:02 -0800 (PST) Received: by 10.86.100.19 with HTTP; Thu, 15 Nov 2007 16:09:02 -0800 (PST) Message-ID: <2a41acea0711151609i64f59719wcd893d0eb89f4cb0@mail.gmail.com> Date: Thu, 15 Nov 2007 16:09:02 -0800 From: "Jack Vogel" To: "Andre Oppermann" In-Reply-To: <473CDE7E.80008@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1B860D81B4F3F44398B9AE84D91C151671D11B@stlex510.dsto.defence.gov.au> <2a41acea0711141712x533bcdbex92df05280311be8e@mail.gmail.com> <473CDE7E.80008@freebsd.org> Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, "Wilkinson, Alex" Subject: Re: I/OAT ... Coming Soon ? 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, 16 Nov 2007 00:09:07 -0000 On Nov 15, 2007 4:04 PM, Andre Oppermann wrote: > Jack Vogel wrote: > > On Nov 14, 2007 5:01 PM, Wilkinson, Alex > > wrote: > >> Hi all, > >> > >> Curious, is I/OAT [http://www.intel.com/go/ioat/] coming to FreeBSD soon > >> ? > > > > LOL, I did a driver for the first version of I/OAT more than a year > > ago, submitted it and interest was half hearted. > > IMHO the biggest drawback (design failure) is the polling requirement > for the work queue. Ideally it would be structured like a NIC with > its DMA engine and rings. I know, at the time I did this Chris Leech the Linux developer was having trouble with an interrupt design, so I figured I'd not bang my head against the wall unnecessarily and follow what he was doing :) Since then however, work has been done and particularly with the CB2 support I believe Linux now does use interrupts, so if I go back and rework the driver I will try and follow that path. There is a goodly amount of work to do this justice, and I have been busy with new NIC hardware so much lately, but I hope to come up for air soon so I will try and get this off the queue :) Cheers, Jack > > The driver needs updating and polishing yet, but interest being what it was > > it hasn't been a real high priority. From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 00:19:03 2007 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 A7D9916A421 for ; Fri, 16 Nov 2007 00:19:03 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 16FCA13C459 for ; Fri, 16 Nov 2007 00:18:59 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 67027 invoked from network); 15 Nov 2007 23:53:08 -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 ; 15 Nov 2007 23:53:08 -0000 Message-ID: <473CE1F8.80502@freebsd.org> Date: Fri, 16 Nov 2007 01:19:04 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Doug Ambrisko References: <200711151640.lAFGeCto021475@ambrisko.com> In-Reply-To: <200711151640.lAFGeCto021475@ambrisko.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Julian Elischer , "Wilkinson, Alex" , Jack Vogel Subject: Re: I/OAT ... Coming Soon ? 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, 16 Nov 2007 00:19:03 -0000 Doug Ambrisko wrote: > Julian Elischer writes: > | Jack Vogel wrote: > | > On Nov 14, 2007 5:01 PM, Wilkinson, Alex > | > wrote: > | >> Hi all, > | >> > | >> Curious, is I/OAT [http://www.intel.com/go/ioat/] coming to FreeBSD soon > | >> ? > | > > | > LOL, I did a driver for the first version of I/OAT more than a year > | > ago, submitted > | > it and interest was half hearted. > | > > | > The driver needs updating and polishing yet, but interest being what it was > | > it hasn't been a real high priority. > | > | I saw what I thought you called a "preliminary" driver. > | There was discussion and I thought you got positive but > | muted (along the lines of "nice.. when will there be hardware for it?") > | and some discussion of how it fits in with TCP offload, but I don't think > | that anyone said they didn't like the idea.. > > FWIW, several of us should have motherboards that support it now. > For example the Dell PE29XX/PE1950 line now has support if you upgrade > old machines to a newer BIOS and then turn it on in the BIOS setup. > I'm not sure what em(4) cards support it. So I think hardware should > be available now. At the time the PE29XX family BIOS did not support it :-( I/OAT is a chipset, or rather memory controller, feature currently only supported in Intel chipsets. If AMD were to support it as well it would have to reside on the CPU die as it is integrates the memory controller. Simply put I/OAT is nothing more than a hardware offloaded bcopy() working on physical addresses. The idea is to free the CPU bandwidth from performing the bcopy itself. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 00:20:18 2007 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 A205716A419 for ; Fri, 16 Nov 2007 00:20:18 +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 2E76813C47E for ; Fri, 16 Nov 2007 00:20:16 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 66950 invoked from network); 15 Nov 2007 23:47:42 -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 ; 15 Nov 2007 23:47:42 -0000 Message-ID: <473CE0B2.5000703@freebsd.org> Date: Fri, 16 Nov 2007 01:13:38 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Jack Vogel References: <1B860D81B4F3F44398B9AE84D91C151671D11B@stlex510.dsto.defence.gov.au> <2a41acea0711141712x533bcdbex92df05280311be8e@mail.gmail.com> <473BA656.7020508@elischer.org> <2a41acea0711150058v5eaa2866v40eb0c0bc65b4ede@mail.gmail.com> In-Reply-To: <2a41acea0711150058v5eaa2866v40eb0c0bc65b4ede@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Julian Elischer , "Wilkinson, Alex" Subject: Re: I/OAT ... Coming Soon ? 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, 16 Nov 2007 00:20:18 -0000 Jack Vogel wrote: > On Nov 14, 2007 5:52 PM, Julian Elischer wrote: >> Jack Vogel wrote: >>> On Nov 14, 2007 5:01 PM, Wilkinson, Alex >>> wrote: >>>> Hi all, >>>> >>>> Curious, is I/OAT [http://www.intel.com/go/ioat/] coming to FreeBSD soon >>>> ? >>> LOL, I did a driver for the first version of I/OAT more than a year >>> ago, submitted >>> it and interest was half hearted. >>> >>> The driver needs updating and polishing yet, but interest being what it was >>> it hasn't been a real high priority. >>> >> I saw what I thought you called a "preliminary" driver. >> There was discussion and I thought you got positive but >> muted (along the lines of "nice.. when will there be hardware for it?") >> and some discussion of how it fits in with TCP offload, but I don't think >> that anyone said they didn't like the idea.. >> >> hmm didn't someone else have an implementation? or am I getting >> my wires crossed on that? > > You are probably right, its been quite a while, and there were > other factors that have effected my perception. > > The driver just for the engine didn't require the stack portion > that Prafulla did, although we need something using the thing :) I/OAT helps with the userland/kernel copying by offloading it into the chipset memory controller. The right place to hook it isn't really the network stack but copyin/copyout and equivalents. m_uiotombuf and uiomove in this case for sockets. > Not sure what other implementation you are thinking of. Linux has it > of course. > > I'd be glad to resurrect the code and get on with it in any case. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 00:22:12 2007 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 E810C16A46B for ; Fri, 16 Nov 2007 00:22:12 +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 4C74913C4BB for ; Fri, 16 Nov 2007 00:22:11 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 67072 invoked from network); 15 Nov 2007 23:56:20 -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 ; 15 Nov 2007 23:56:20 -0000 Message-ID: <473CE2B9.8010201@freebsd.org> Date: Fri, 16 Nov 2007 01:22:17 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Scott Ullrich References: <200711151729.lAFHTbiq024351@ambrisko.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Julian Elischer , "Wilkinson, Alex" , Jack Vogel Subject: Re: I/OAT ... Coming Soon ? 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, 16 Nov 2007 00:22:13 -0000 Scott Ullrich wrote: > On 11/15/07, Doug Ambrisko wrote: >> Hmm, I forgot about the 2970 which are AMD based. Can you check the >> BIOS to see if there is an option to turn it on? I think this is an >> Intel feature. AMD might have something close? We have one 2970 >> that we've played with a little but not much. I can't say for sure >> if it has it. > > Right you are. As of BIOS 1.2.2 I do not see a I/OAT option. Guess > I will need to pick up a different server as we are interested in what > kind of packet forwarding rate increase that this feature might bring > on a heavily loaded firewall. Not much. Unless your firewall is in usermode. Otherwise the data stays in the kernel and I/OAT is of not help as no copying happens. Your CPU is probably spending half of its clock cycles waiting on cache misses from newly arrived packets. Some Intel chipset integrated gige ports have a cache prefetch feature (duno whether our driver supports it) that would help quite a bit for your case. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 00:25:45 2007 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 E301B16A41A for ; Fri, 16 Nov 2007 00:25:45 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 76A8B13C459 for ; Fri, 16 Nov 2007 00:25:44 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so659937nfb for ; Thu, 15 Nov 2007 16:25:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=AXKXXTeznBt5jjWX/NXF4DdsA1haXC6lS2yx4JFMq5s=; b=SmKvcDOmBWGhlc4PIAll/hCJDSA3cIUb0RRezVbANCHNQQhZLEhRt37K730v00chaW8KUnjrt6K+eriOz5pwn2KxqVWQarRnWZQc+PpVUi9jJ1TLPdr+m0eak4ps9Mr9s66ZK5B/2zJ7oDMACVNG06Q1gxYIM5YNrFbyn2qRSsc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FTe8kDcHDgijAnutCHi94F4mkNLnW3C15FdYExuSfw84Y/bu7Xt6HdjTaMWhoytta6MBVWuANNfoG+NRvSgW4CPapmGIdbdvG0IkLXW4cNUiIh67sm//HuvKBzoK9KfNbz1M42OihJErdhlJicycTggfnZqZ9OCFv9EyDQ1WleE= Received: by 10.86.54.3 with SMTP id c3mr1161196fga.1195172743943; Thu, 15 Nov 2007 16:25:43 -0800 (PST) Received: by 10.86.100.19 with HTTP; Thu, 15 Nov 2007 16:25:43 -0800 (PST) Message-ID: <2a41acea0711151625q5a994cf3ja0d5f14b0670ca3@mail.gmail.com> Date: Thu, 15 Nov 2007 16:25:43 -0800 From: "Jack Vogel" To: "Andre Oppermann" In-Reply-To: <473CE2B9.8010201@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200711151729.lAFHTbiq024351@ambrisko.com> <473CE2B9.8010201@freebsd.org> Cc: freebsd-net@freebsd.org, Scott Ullrich , freebsd-current@freebsd.org, Julian Elischer , "Wilkinson, Alex" Subject: Re: I/OAT ... Coming Soon ? 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, 16 Nov 2007 00:25:46 -0000 On Nov 15, 2007 4:22 PM, Andre Oppermann wrote: > > Scott Ullrich wrote: > > On 11/15/07, Doug Ambrisko wrote: > >> Hmm, I forgot about the 2970 which are AMD based. Can you check the > >> BIOS to see if there is an option to turn it on? I think this is an > >> Intel feature. AMD might have something close? We have one 2970 > >> that we've played with a little but not much. I can't say for sure > >> if it has it. > > > > Right you are. As of BIOS 1.2.2 I do not see a I/OAT option. Guess > > I will need to pick up a different server as we are interested in what > > kind of packet forwarding rate increase that this feature might bring > > on a heavily loaded firewall. > > Not much. Unless your firewall is in usermode. Otherwise the data > stays in the kernel and I/OAT is of not help as no copying happens. > Your CPU is probably spending half of its clock cycles waiting on > cache misses from newly arrived packets. Some Intel chipset integrated > gige ports have a cache prefetch feature (duno whether our driver > supports it) that would help quite a bit for your case. What might help this is multiqueue support on the receive AND send, and stack support for the same. Not sure what the stack changes would look like, but I know there's interest in this sort of thing, so naturally I'd be into it :) Jack From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 00:26:48 2007 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 D60C016A469 for ; Fri, 16 Nov 2007 00:26:48 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id 4C30713C47E for ; Fri, 16 Nov 2007 00:26:48 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so660159nfb for ; Thu, 15 Nov 2007 16:26:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=o1GvOKyNMSU9M99KhwLgLkdZ67CWc0kv+Kch9feiMlY=; b=Tvs+U0GmAEq6Gla+vx1zwm7UFdaQsKx0nOZ+Vj8/K8/umJl1UzoE7xqCp0touhAkIcYcQql6730hMc3MUVr91w0xm82t+Ez5NvIQjIx9vR43LxHt5htU5YOtgyZ5tFu2zqRj2zdrHzHuU35apmHc3p5tmsZi/UdW0n0Um0UXw0s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OoUyE77Ek1fKje7fEYEhJWYBOqcQAPZuUA2JkhXT0reVh6dZ5uIKDy7hUVf1OZ6KDchc9AxMeGx60KwgY8+5jGx2IECQns+HwUYJmpP9XS9ezt7atXdKXu74KN2JCadZutFhh890wwE+qgFWnIAcz2sztCmVkJs7Yls55GMO1PA= Received: by 10.86.58.3 with SMTP id g3mr1172038fga.1195172807126; Thu, 15 Nov 2007 16:26:47 -0800 (PST) Received: by 10.86.100.19 with HTTP; Thu, 15 Nov 2007 16:26:46 -0800 (PST) Message-ID: <2a41acea0711151626u99fb8e5l55bf5159fb808a01@mail.gmail.com> Date: Thu, 15 Nov 2007 16:26:46 -0800 From: "Jack Vogel" To: "Andre Oppermann" In-Reply-To: <2a41acea0711151625q5a994cf3ja0d5f14b0670ca3@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200711151729.lAFHTbiq024351@ambrisko.com> <473CE2B9.8010201@freebsd.org> <2a41acea0711151625q5a994cf3ja0d5f14b0670ca3@mail.gmail.com> Cc: freebsd-net@freebsd.org, Scott Ullrich , freebsd-current@freebsd.org, Julian Elischer , "Wilkinson, Alex" Subject: Re: I/OAT ... Coming Soon ? 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, 16 Nov 2007 00:26:49 -0000 On Nov 15, 2007 4:25 PM, Jack Vogel wrote: > > On Nov 15, 2007 4:22 PM, Andre Oppermann wrote: > > > > Scott Ullrich wrote: > > > On 11/15/07, Doug Ambrisko wrote: > > >> Hmm, I forgot about the 2970 which are AMD based. Can you check the > > >> BIOS to see if there is an option to turn it on? I think this is an > > >> Intel feature. AMD might have something close? We have one 2970 > > >> that we've played with a little but not much. I can't say for sure > > >> if it has it. > > > > > > Right you are. As of BIOS 1.2.2 I do not see a I/OAT option. Guess > > > I will need to pick up a different server as we are interested in what > > > kind of packet forwarding rate increase that this feature might bring > > > on a heavily loaded firewall. > > > > Not much. Unless your firewall is in usermode. Otherwise the data > > stays in the kernel and I/OAT is of not help as no copying happens. > > Your CPU is probably spending half of its clock cycles waiting on > > cache misses from newly arrived packets. Some Intel chipset integrated > > gige ports have a cache prefetch feature (duno whether our driver > > supports it) that would help quite a bit for your case. > > What might help this is multiqueue support on the receive AND send, > and stack support for the same. Not sure what the stack changes > would look like, but I know there's interest in this sort of thing, so > naturally I'd be into it :) > > Jack > OH, and I should quickly add, that this only makes sense with hardware that supports it, ie with MSI/X. Jack From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 00:30:47 2007 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 93FDA16A417 for ; Fri, 16 Nov 2007 00:30:47 +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 0835A13C45A for ; Fri, 16 Nov 2007 00:30:46 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 66853 invoked from network); 15 Nov 2007 23:38:18 -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 ; 15 Nov 2007 23:38:18 -0000 Message-ID: <473CDE7E.80008@freebsd.org> Date: Fri, 16 Nov 2007 01:04:14 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Jack Vogel References: <1B860D81B4F3F44398B9AE84D91C151671D11B@stlex510.dsto.defence.gov.au> <2a41acea0711141712x533bcdbex92df05280311be8e@mail.gmail.com> In-Reply-To: <2a41acea0711141712x533bcdbex92df05280311be8e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, "Wilkinson, Alex" Subject: Re: I/OAT ... Coming Soon ? 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, 16 Nov 2007 00:30:47 -0000 Jack Vogel wrote: > On Nov 14, 2007 5:01 PM, Wilkinson, Alex > wrote: >> Hi all, >> >> Curious, is I/OAT [http://www.intel.com/go/ioat/] coming to FreeBSD soon >> ? > > LOL, I did a driver for the first version of I/OAT more than a year > ago, submitted it and interest was half hearted. IMHO the biggest drawback (design failure) is the polling requirement for the work queue. Ideally it would be structured like a NIC with its DMA engine and rings. > The driver needs updating and polishing yet, but interest being what it was > it hasn't been a real high priority. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 00:34:13 2007 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 A742416A476 for ; Fri, 16 Nov 2007 00:34:13 +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 1409713C459 for ; Fri, 16 Nov 2007 00:34:05 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 67272 invoked from network); 16 Nov 2007 00:08:10 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 16 Nov 2007 00:08:10 -0000 Message-ID: <473CE57E.7010303@freebsd.org> Date: Fri, 16 Nov 2007 01:34:06 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Jack Vogel References: <1B860D81B4F3F44398B9AE84D91C151671D11B@stlex510.dsto.defence.gov.au> <2a41acea0711141712x533bcdbex92df05280311be8e@mail.gmail.com> <473CDE7E.80008@freebsd.org> <2a41acea0711151609i64f59719wcd893d0eb89f4cb0@mail.gmail.com> In-Reply-To: <2a41acea0711151609i64f59719wcd893d0eb89f4cb0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, "Wilkinson, Alex" Subject: Re: I/OAT ... Coming Soon ? 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, 16 Nov 2007 00:34:13 -0000 Jack Vogel wrote: > On Nov 15, 2007 4:04 PM, Andre Oppermann wrote: >> Jack Vogel wrote: >>> On Nov 14, 2007 5:01 PM, Wilkinson, Alex >>> wrote: >>>> Hi all, >>>> >>>> Curious, is I/OAT [http://www.intel.com/go/ioat/] coming to FreeBSD soon >>>> ? >>> LOL, I did a driver for the first version of I/OAT more than a year >>> ago, submitted it and interest was half hearted. >> IMHO the biggest drawback (design failure) is the polling requirement >> for the work queue. Ideally it would be structured like a NIC with >> its DMA engine and rings. > > I know, at the time I did this Chris Leech the Linux developer was having > trouble with an interrupt design, so I figured I'd not bang my head against > the wall unnecessarily and follow what he was doing :) > > Since then however, work has been done and particularly with the CB2 > support I believe Linux now does use interrupts, so if I go back and rework > the driver I will try and follow that path. Actually it shouldn't be too hard. I can provide you with the entry points and a taskqueue entry. The I/OAT support can be done just like a driver serving the taskqueue. The entry points for m_uiotombuf et al would consider offloading if a certain size threshold is met and the copy request is tagged with M_WAITOK. The virtual to physical memory lookup is probably costly though. I don't think it supports the TLB as that is only available within the CPU. How is cache coherency solved? It'd be helpful if the documentation for I/OAT were available. The Core2 and AMD64 CPUs have very high memory bandwidth with low latency. Is I/OAT still a significant enough win compared to the implementation effort required? -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 00:41:50 2007 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 67F0A16A421 for ; Fri, 16 Nov 2007 00:41:50 +0000 (UTC) (envelope-from dd@freebsd.org) Received: from mail.trit.net (mail.trit.net [208.75.88.227]) by mx1.freebsd.org (Postfix) with ESMTP id 51EF613C45D for ; Fri, 16 Nov 2007 00:41:46 +0000 (UTC) (envelope-from dd@freebsd.org) Received: from beaver.trit.net (beaver.trit.net [208.75.88.61]) by mail.trit.net (Postfix) with ESMTP id DB27736509; Fri, 16 Nov 2007 00:14:29 +0000 (UTC) Received: from beaver.trit.net (localhost [127.0.0.1]) by beaver.trit.net (8.14.1/8.14.1) with ESMTP id lAG0ETRW025711; Fri, 16 Nov 2007 00:14:29 GMT (envelope-from dd@freebsd.org) Received: (from dima@localhost) by beaver.trit.net (8.14.1/8.14.1/Submit) id lAG0ET35025710; Fri, 16 Nov 2007 00:14:29 GMT (envelope-from dd@freebsd.org) X-Authentication-Warning: beaver.trit.net: dima set sender to dd@freebsd.org using -f Date: Fri, 16 Nov 2007 00:14:29 +0000 From: Dima Dorfman To: Brian Hawk Message-ID: <20071116001429.GE1499@beaver.trit.net> References: <473C5593.4080407@tnetus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <473C5593.4080407@tnetus.com> X-PGP-Key: 69FAE582 (https://www.trit.org/~dima/dima.asc) X-PGP-Fingerprint: B340 8338 7DA3 4D61 7632 098E 0730 055B 69FA E582 User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: freebsd-net@freebsd.org Subject: Re: Interface address sourced packets go thru default gateway on another interface 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, 16 Nov 2007 00:41:50 -0000 Brian Hawk wrote: > since it shouldn't really happen and it used not to happen. > Everything was working fine until I don't know when and why, now I > cannot send any packets out thru my xl1 interface by binding its > source address to the packets. I don't think it ever worked the way you described. The source IP address doesn't usually affect how replies will be routed on the way out. You can fix this with policy routing rules. Here's an example with PF: : pass out quick route-to ($other_if $other_gw) from ($other_if) $other_if is the name of the interface and $other_gw is the name of the gateway through that interface. You need to do this for every interface other than the one used by the default gateway. The rule says: If the packet is coming from an IP address assigned to $other_if, then send it through $other_gw. If you use stateful inspection, you need corresponding reply-to rules in the other direction: : pass in quick reply-to ($other_if $other_gw) inet proto tcp to ($other_if) port ssh keep state This idiom is useful on systems with multiple indepenent Internet connections. With these rules, failure of the primary connection will not prevent full connectivity through the secondary. -- Dima From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 00:43:34 2007 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 40D2416A41A for ; Fri, 16 Nov 2007 00:43:34 +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 8AF3513C45A for ; Fri, 16 Nov 2007 00:43:25 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 67423 invoked from network); 16 Nov 2007 00:17:18 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 16 Nov 2007 00:17:18 -0000 Message-ID: <473CE7A2.6080804@freebsd.org> Date: Fri, 16 Nov 2007 01:43:14 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Jack Vogel References: <200711151729.lAFHTbiq024351@ambrisko.com> <473CE2B9.8010201@freebsd.org> <2a41acea0711151625q5a994cf3ja0d5f14b0670ca3@mail.gmail.com> In-Reply-To: <2a41acea0711151625q5a994cf3ja0d5f14b0670ca3@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Scott Ullrich , freebsd-current@freebsd.org, Julian Elischer , "Wilkinson, Alex" Subject: Re: I/OAT ... Coming Soon ? 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, 16 Nov 2007 00:43:34 -0000 Jack Vogel wrote: > On Nov 15, 2007 4:22 PM, Andre Oppermann wrote: >> Scott Ullrich wrote: >>> On 11/15/07, Doug Ambrisko wrote: >>>> Hmm, I forgot about the 2970 which are AMD based. Can you check the >>>> BIOS to see if there is an option to turn it on? I think this is an >>>> Intel feature. AMD might have something close? We have one 2970 >>>> that we've played with a little but not much. I can't say for sure >>>> if it has it. >>> Right you are. As of BIOS 1.2.2 I do not see a I/OAT option. Guess >>> I will need to pick up a different server as we are interested in what >>> kind of packet forwarding rate increase that this feature might bring >>> on a heavily loaded firewall. >> Not much. Unless your firewall is in usermode. Otherwise the data >> stays in the kernel and I/OAT is of not help as no copying happens. >> Your CPU is probably spending half of its clock cycles waiting on >> cache misses from newly arrived packets. Some Intel chipset integrated >> gige ports have a cache prefetch feature (duno whether our driver >> supports it) that would help quite a bit for your case. > > What might help this is multiqueue support on the receive AND send, > and stack support for the same. Not sure what the stack changes > would look like, but I know there's interest in this sort of thing, so > naturally I'd be into it :) Dunno if multiqueue is a big win here. You have to make sure that packet order is maintained which kinda implies a single queue. Of course one could spread some load with fixed hashes to keep flows together. The reason a small 1GHz embedded MIPS CPU with integrated GigE ports can do more than 1Mpps is the cache prefetching feature. The thingies generally move the first 128bytes of every packet received into the L2 cache. This is enough for the headers and to perform a lookup on the routing table or the TCP/UDP control block table without much delay. The normal PC architecture is quite broken in that regard as everything that comes in through DMA is in cold main memory. Once the CPU wants to look at it, it has to wait an insane amount of time. That times the number of packets. In pure forwarding applications (routing) it wastes half of all CPU cycles with waiting on main memory. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 01:08:21 2007 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 EA86A16A419 for ; Fri, 16 Nov 2007 01:08:21 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from rn-out-0102.google.com (rn-out-0910.google.com [64.233.170.189]) by mx1.freebsd.org (Postfix) with ESMTP id 92D5D13C458 for ; Fri, 16 Nov 2007 01:08:20 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by rn-out-0102.google.com with SMTP id s42so618713rnb for ; Thu, 15 Nov 2007 17:08:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=496dyub4Ghj/Qlbkn30ZGJcnzZv0swD5zFiCysx3qiw=; b=BFXvluDqgQUhvdkRPh70hPc8gJSSaUWPeq0mLLfNC4NJXKIT8+2pdkO/A/3RXqK4CR6/ZtEYZLSd5LkRbdDrRL+5scJOkhJmrqxqx0lDJMH1bu6vfgURh7QC+pjX+mPXcMfqwdMV9pCBf2P/yUK90MAqI2Z/6h7JVEhUPvgS0wo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KUPOHVGcaZXpNrf76CnLEXJbzb4xa3CxAi7gJE4S4zQNA0H8SqiX6G8IqFGpyAiQKTXKl/zUVnY+0NXuMcUN1leK7X6TP8YIX039VpH/v/Ez0jMbMJwXSA1OiUV0QSPpFJZW1EmsDDKjHCbkDSWnbSJyMyn6MSJUTPy1peDLs8c= Received: by 10.142.240.9 with SMTP id n9mr481838wfh.1195175298759; Thu, 15 Nov 2007 17:08:18 -0800 (PST) Received: by 10.142.230.18 with HTTP; Thu, 15 Nov 2007 17:08:18 -0800 (PST) Message-ID: Date: Thu, 15 Nov 2007 17:08:18 -0800 From: "Kip Macy" To: "Jack Vogel" In-Reply-To: <2a41acea0711151625q5a994cf3ja0d5f14b0670ca3@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200711151729.lAFHTbiq024351@ambrisko.com> <473CE2B9.8010201@freebsd.org> <2a41acea0711151625q5a994cf3ja0d5f14b0670ca3@mail.gmail.com> Cc: Andre Oppermann , freebsd-net@freebsd.org, Scott Ullrich , freebsd-current@freebsd.org, Julian Elischer , "Wilkinson, Alex" Subject: Re: I/OAT ... Coming Soon ? 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, 16 Nov 2007 01:08:22 -0000 On Nov 15, 2007 4:25 PM, Jack Vogel wrote: > On Nov 15, 2007 4:22 PM, Andre Oppermann wrote: > > > > Scott Ullrich wrote: > > > On 11/15/07, Doug Ambrisko wrote: > > >> Hmm, I forgot about the 2970 which are AMD based. Can you check the > > >> BIOS to see if there is an option to turn it on? I think this is an > > >> Intel feature. AMD might have something close? We have one 2970 > > >> that we've played with a little but not much. I can't say for sure > > >> if it has it. > > > > > > Right you are. As of BIOS 1.2.2 I do not see a I/OAT option. Guess > > > I will need to pick up a different server as we are interested in what > > > kind of packet forwarding rate increase that this feature might bring > > > on a heavily loaded firewall. > > > > Not much. Unless your firewall is in usermode. Otherwise the data > > stays in the kernel and I/OAT is of not help as no copying happens. > > Your CPU is probably spending half of its clock cycles waiting on > > cache misses from newly arrived packets. Some Intel chipset integrated > > gige ports have a cache prefetch feature (duno whether our driver > > supports it) that would help quite a bit for your case. > > What might help this is multiqueue support on the receive AND send, > and stack support for the same. Not sure what the stack changes > would look like, but I know there's interest in this sort of thing, so > naturally I'd be into it :) I have support for this already in my ethng branch. I'll be adding support for zero-copy send and receive for TOE to my toestack branch as soon as I feel better :-(. It would probably not be that hard to generalize it to I/OAT. -Kip From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 01:13:18 2007 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 5127716A417; Fri, 16 Nov 2007 01:13:18 +0000 (UTC) (envelope-from kmacy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2D78F13C455; Fri, 16 Nov 2007 01:13:18 +0000 (UTC) (envelope-from kmacy@FreeBSD.org) Received: from freefall.freebsd.org (kmacy@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id lAG1DFNv065455; Fri, 16 Nov 2007 01:13:15 GMT (envelope-from kmacy@freefall.freebsd.org) Received: (from kmacy@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id lAG1DFq0065451; Fri, 16 Nov 2007 01:13:15 GMT (envelope-from kmacy) Date: Fri, 16 Nov 2007 01:13:15 GMT Message-Id: <200711160113.lAG1DFq0065451@freefall.freebsd.org> To: kmacy@FreeBSD.org, darrenr@FreeBSD.org, freebsd-net@FreeBSD.org From: kmacy@FreeBSD.org Cc: Subject: Re: kern/62374: panic: free: multiple frees 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, 16 Nov 2007 01:13:18 -0000 Synopsis: panic: free: multiple frees Responsible-Changed-From-To: darrenr->freebsd-net Responsible-Changed-By: kmacy Responsible-Changed-When: Fri Nov 16 01:11:51 UTC 2007 Responsible-Changed-Why: Doesn't look like ipf - need confirmation that it is still an issue. http://www.freebsd.org/cgi/query-pr.cgi?pr=62374 From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 02:35:01 2007 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 2324616A46D; Fri, 16 Nov 2007 02:35:01 +0000 (UTC) (envelope-from kmacy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EF69313C44B; Fri, 16 Nov 2007 02:35:00 +0000 (UTC) (envelope-from kmacy@FreeBSD.org) Received: from freefall.freebsd.org (kmacy@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id lAG2Z0Gh071390; Fri, 16 Nov 2007 02:35:00 GMT (envelope-from kmacy@freefall.freebsd.org) Received: (from kmacy@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id lAG2Z0qx071386; Fri, 16 Nov 2007 02:35:00 GMT (envelope-from kmacy) Date: Fri, 16 Nov 2007 02:35:00 GMT Message-Id: <200711160235.lAG2Z0qx071386@freefall.freebsd.org> To: dgilbert@daveg.ca, kmacy@FreeBSD.org, freebsd-net@FreeBSD.org From: kmacy@FreeBSD.org Cc: Subject: Re: kern/115360: [ipv6] IPv6 address and if_bridge don't play well together. 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, 16 Nov 2007 02:35:01 -0000 Synopsis: [ipv6] IPv6 address and if_bridge don't play well together. State-Changed-From-To: open->feedback State-Changed-By: kmacy State-Changed-When: Fri Nov 16 02:34:19 UTC 2007 State-Changed-Why: Awaiting feedback. http://www.freebsd.org/cgi/query-pr.cgi?pr=115360 From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 02:40:01 2007 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 B012B16A418; Fri, 16 Nov 2007 02:40:01 +0000 (UTC) (envelope-from kmacy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 890CE13C442; Fri, 16 Nov 2007 02:40:01 +0000 (UTC) (envelope-from kmacy@FreeBSD.org) Received: from freefall.freebsd.org (kmacy@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id lAG2e1qZ071461; Fri, 16 Nov 2007 02:40:01 GMT (envelope-from kmacy@freefall.freebsd.org) Received: (from kmacy@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id lAG2e14u071457; Fri, 16 Nov 2007 02:40:01 GMT (envelope-from kmacy) Date: Fri, 16 Nov 2007 02:40:01 GMT Message-Id: <200711160240.lAG2e14u071457@freefall.freebsd.org> To: netch@segfault.kiev.ua, kmacy@FreeBSD.org, freebsd-net@FreeBSD.org, kmacy@FreeBSD.org From: kmacy@FreeBSD.org Cc: Subject: Re: kern/21998: [socket] [patch] ident only for outgoing connections 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, 16 Nov 2007 02:40:01 -0000 Synopsis: [socket] [patch] ident only for outgoing connections State-Changed-From-To: suspended->feedback State-Changed-By: kmacy State-Changed-When: Fri Nov 16 02:38:32 UTC 2007 State-Changed-Why: Need feedback. Responsible-Changed-From-To: freebsd-net->kmacy Responsible-Changed-By: kmacy Responsible-Changed-When: Fri Nov 16 02:38:32 UTC 2007 Responsible-Changed-Why: Need to confirm that this issue still applies. http://www.freebsd.org/cgi/query-pr.cgi?pr=21998 From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 03:09:16 2007 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 D74C616A468; Fri, 16 Nov 2007 03:09:16 +0000 (UTC) (envelope-from kmacy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B679813C4C5; Fri, 16 Nov 2007 03:09:16 +0000 (UTC) (envelope-from kmacy@FreeBSD.org) Received: from freefall.freebsd.org (kmacy@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id lAG39Geh073121; Fri, 16 Nov 2007 03:09:16 GMT (envelope-from kmacy@freefall.freebsd.org) Received: (from kmacy@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id lAG39Fkk073117; Fri, 16 Nov 2007 03:09:15 GMT (envelope-from kmacy) Date: Fri, 16 Nov 2007 03:09:15 GMT Message-Id: <200711160309.lAG39Fkk073117@freefall.freebsd.org> To: jacek@ipv6.jacek.it.pl, kmacy@FreeBSD.org, freebsd-net@FreeBSD.org From: kmacy@FreeBSD.org Cc: Subject: Re: kern/117456: [ipv6] ipv6 neighbour discovery / bce multicast problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2007 03:09:16 -0000 Synopsis: [ipv6] ipv6 neighbour discovery / bce multicast problem State-Changed-From-To: open->closed State-Changed-By: kmacy State-Changed-When: Fri Nov 16 03:08:39 UTC 2007 State-Changed-Why: Fixed by Mike Karels. http://www.freebsd.org/cgi/query-pr.cgi?pr=117456 From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 05:39:45 2007 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 BFD6A16A418 for ; Fri, 16 Nov 2007 05:39:45 +0000 (UTC) (envelope-from brian@tnetus.com) Received: from k2smtpout01-02.prod.mesa1.secureserver.net (k2smtpout01-02.prod.mesa1.secureserver.net [64.202.189.89]) by mx1.freebsd.org (Postfix) with SMTP id A1C4913C43E for ; Fri, 16 Nov 2007 05:39:45 +0000 (UTC) (envelope-from brian@tnetus.com) Received: (qmail 6713 invoked from network); 16 Nov 2007 05:39:38 -0000 Received: from unknown (HELO tnetus.com) (68.178.207.93) by k2smtpout01-02.prod.mesa1.secureserver.net (64.202.189.89) with SMTP; 16 Nov 2007 05:39:38 -0000 Received: from [10.1.1.134] ([85.97.4.79]) by tnetus.com with hMailServer ; Fri, 16 Nov 2007 00:39:41 -0500 Message-ID: <473D2D17.3060504@tnetus.com> Date: Fri, 16 Nov 2007 07:39:35 +0200 From: Brian Hawk User-Agent: Thunderbird 2.0.0.7pre (Windows/20071019) MIME-Version: 1.0 To: Steve Bertrand References: <473C5593.4080407@tnetus.com> <473C6D51.6070500@ibctech.ca> In-Reply-To: <473C6D51.6070500@ibctech.ca> Content-Type: text/plain; charset=ISO-8859-9; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Interface address sourced packets go thru default gateway on another interface 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, 16 Nov 2007 05:39:45 -0000 Here's the routing table, #~>netstat -rn Internet: Destination Gateway Flags Refs Use Netif Expire default 85.97.0.1 UGS 0 25211312 tun0 10 10.1.1.222 UGS 0 3407666 xl0 10.1.1/24 link#2 UC 0 0 xl0 10.1.1.42 00:50:8b:44:1a:91 UHLW 0 1 xl0 469 10.1.1.87 00:0e:a6:a4:56:1c UHLW 0 9716 xl0 126 10.1.1.99 link#2 UHLW 0 1 xl0 10.1.1.134 00:15:c5:ad:08:f0 UHLW 0 1413 xl0 1015 10.1.1.222 00:50:da:4e:e7:e2 UHLW 1 1773 lo0 10.1.1.225 00:b0:d0:20:b7:9e UHLW 0 18460272 xl0 254 85.97.0.1 85.97.4.79 UH 1 0 tun0 127.0.0.1 127.0.0.1 UH 0 1317879 lo0 192.168.0 link#3 UCS 0 0 xl1 192.168.1 link#1 UC 0 0 rl0 192.168.1.100 link#1 UHLW 0 4 rl0 212.64.206.176/29 link#3 UC 0 0 xl1 212.64.206.180 00:04:76:9b:3d:f8 UHLW 0 2318 lo0 212.64.206.180 is the leased-line interface. Steve Bertrand wrote: >> My problem is, packets generated with A.B.C.D source address does not go >> out thru xl1 but tun0 (which is the default gw). The problem also >> happens when an outsite packet destined for A.B.C.D arrives. The packet >> correctly arrives from xl1 interface but the response goes out from >> tun0. This is driving me crazy since it shouldn't really happen and it >> used not to happen. Everything was working fine until I don't know when >> and why, now I cannot send any packets out thru my xl1 interface by >> binding its source address to the packets. >> > > Show the output to: > > # netstat -rn > > ...are you *sure* that it hasn't always worked this way? > > Steve > From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 06:02:12 2007 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 6EAE916A417 for ; Fri, 16 Nov 2007 06:02:12 +0000 (UTC) (envelope-from brian@tnetus.com) Received: from k2smtpout03-01.prod.mesa1.secureserver.net (k2smtpout03-01.prod.mesa1.secureserver.net [64.202.189.171]) by mx1.freebsd.org (Postfix) with SMTP id 3B44013C468 for ; Fri, 16 Nov 2007 06:02:11 +0000 (UTC) (envelope-from brian@tnetus.com) Received: (qmail 4586 invoked from network); 16 Nov 2007 06:02:03 -0000 Received: from unknown (HELO tnetus.com) (68.178.207.93) by k2smtpout03-01.prod.mesa1.secureserver.net (64.202.189.171) with SMTP; 16 Nov 2007 06:02:03 -0000 Received: from [10.1.1.134] ([85.97.4.79]) by tnetus.com with hMailServer ; Fri, 16 Nov 2007 01:02:06 -0500 Message-ID: <473D3258.9040203@tnetus.com> Date: Fri, 16 Nov 2007 08:02:00 +0200 From: Brian Hawk User-Agent: Thunderbird 2.0.0.7pre (Windows/20071019) MIME-Version: 1.0 To: Dima Dorfman References: <473C5593.4080407@tnetus.com> <20071116001429.GE1499@beaver.trit.net> In-Reply-To: <20071116001429.GE1499@beaver.trit.net> Content-Type: text/plain; charset=ISO-8859-9; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Interface address sourced packets go thru default gateway on another interface 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, 16 Nov 2007 06:02:12 -0000 Dima Dorfman wrote: > I don't think it ever worked the way you described. The source IP > address doesn't usually affect how replies will be routed on the way > out. > Then what would be the reason to bind a connection to a specific source address? We do ping -S A.B.C.D x.y.z.t to make ping send packets to x.y.z.t over A.B.C.D's interface (and source address) or telnet -s A.B.C.D x.y.z.t I believe binding an IP's source address to an interface address (instead of INADDR_ANY) is to make packets go out from *that* interface, not the default gw. > You can fix this with policy routing rules. Here's an example with PF: > > : pass out quick route-to ($other_if $other_gw) from ($other_if) > > I really am an ipfilter fan. It's greate that pf support this. But I think ipfilter doesn't yet. At least not the version I'm using (v3.4.35). -Brian From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 06:18:40 2007 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 C899516A41B for ; Fri, 16 Nov 2007 06:18:40 +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 B4CBE13C45D for ; Fri, 16 Nov 2007 06:18:40 +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, 15 Nov 2007 22:18:39 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 4E888126A0E; Thu, 15 Nov 2007 22:18:39 -0800 (PST) Message-ID: <473D363E.20305@elischer.org> Date: Thu, 15 Nov 2007 22:18:38 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Brian Hawk References: <473C5593.4080407@tnetus.com> <20071116001429.GE1499@beaver.trit.net> <473D3258.9040203@tnetus.com> In-Reply-To: <473D3258.9040203@tnetus.com> Content-Type: text/plain; charset=ISO-8859-9; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Dima Dorfman Subject: Re: Interface address sourced packets go thru default gateway on another interface 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, 16 Nov 2007 06:18:40 -0000 Brian Hawk wrote: > Dima Dorfman wrote: >> I don't think it ever worked the way you described. The source IP >> address doesn't usually affect how replies will be routed on the way >> out. >> > Then what would be the reason to bind a connection to a specific source > address? We do > ping -S A.B.C.D x.y.z.t > to make ping send packets to x.y.z.t over A.B.C.D's interface (and > source address) or > telnet -s A.B.C.D x.y.z.t no binding does not affect the interface the packet goes out. in affects the address that return packets will be sent to but that's about all. > > I believe binding an IP's source address to an interface address > (instead of INADDR_ANY) is to make packets go out from *that* interface, > not the default gw. >> You can fix this with policy routing rules. Here's an example with PF: >> >> : pass out quick route-to ($other_if $other_gw) from ($other_if) >> >> > I really am an ipfilter fan. It's greate that pf support this. But I > think ipfilter doesn't yet. At least not the version I'm using (v3.4.35). ipfw can do it with fwd {next hop} ip from ${other_if} to ${where-ever} you can even do fwd tablearg ip from ${src} to table(x) to implement a second routing table for packets from ${src} > > -Brian > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 06:28:43 2007 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 9486F16A4A1; Fri, 16 Nov 2007 06:28:43 +0000 (UTC) (envelope-from dgilbert@daveg.ca) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.freebsd.org (Postfix) with ESMTP id 53ED913C45A; Fri, 16 Nov 2007 06:28:43 +0000 (UTC) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id AFB37C2C8; Fri, 16 Nov 2007 01:06:42 -0500 (EST) Received: by canoe.dclg.ca (Postfix, from userid 101) id 0D78E61C89; Fri, 16 Nov 2007 01:06:45 -0500 (EST) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18237.13172.886763.669498@canoe.dclg.ca> Date: Fri, 16 Nov 2007 01:06:44 -0500 To: kmacy@FreeBSD.org In-Reply-To: <200711160235.lAG2Z0qx071386@freefall.freebsd.org> References: <200711160235.lAG2Z0qx071386@freefall.freebsd.org> X-Mailer: VM 7.17 under 21.4 (patch 20) "Double Solitaire" XEmacs Lucid Cc: freebsd-net@FreeBSD.org, dgilbert@daveg.ca Subject: Re: kern/115360: [ipv6] IPv6 address and if_bridge don't play well together. 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, 16 Nov 2007 06:28:43 -0000 >>>>> "kmacy" == kmacy writes: kmacy> Synopsis: [ipv6] IPv6 address and if_bridge don't play well kmacy> together. State-Changed-From-To: open->feedback kmacy> State-Changed-By: kmacy State-Changed-When: Fri Nov 16 02:34:19 kmacy> UTC 2007 State-Changed-Why: kmacy> Awaiting feedback. kmacy> http://www.freebsd.org/cgi/query-pr.cgi?pr=115360 Hrm. I've tried this several ways. None work. Machine calls itself 6.2-STABLE compiled May 13th. It has a 4 port card running the dc driver and an em driver GigE card. dc0 receives cable internet in, dc1, dc2 and em0 are bridged with if_bridge, dc3 receieve pppoe DSL internet in (through mpd4 --- so ng0 exists for that). gif0 brings ipv6 in and "tun10" is a custom tunneling daemon that uses both the cable and the DSL for reliability. Anyways... the pertinant configuration is bridge0 containing dc1, dc2 and em0. As follows (I've cut out interfaces that arn't part of this): dc1: flags=8943 mtu 1500 options=8 inet6 fe80::280:c8ff:fec9:2231%dc1 prefixlen 64 scopeid 0x2 inet 66.96.20.33 netmask 0xffffffe0 broadcast 66.96.20.63 inet 192.168.110.1 netmask 0xffffff00 broadcast 192.168.110.255 inet6 2001:1928:1::1 prefixlen 80 inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255 inet 192.168.0.10 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:80:c8:c9:22:31 media: Ethernet autoselect (100baseTX ) status: active dc2: flags=8943 mtu 1500 options=8 inet6 fe80::280:c8ff:fec9:2232%dc2 prefixlen 64 scopeid 0x3 ether 00:80:c8:c9:22:32 media: Ethernet autoselect (none) status: no carrier em0: flags=8943 mtu 1500 options=8 inet6 fe80::20e:cff:febc:6f87%em0 prefixlen 64 scopeid 0x5 inet6 2001:1928:1::1 prefixlen 64 ether 00:0e:0c:bc:6f:87 media: Ethernet autoselect (1000baseTX ) status: active bridge0: flags=8843 mtu 1500 ether 7a:10:5b:2c:d0:77 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto stp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 0 ifcost 0 port 0 member: em0 flags=143 member: dc2 flags=143 member: dc1 flags=143 Now... if I put 2001:1928:1::1 on bridge0 (only), nobody get's ipv6 service. Note that dc2 is currently not connected. In this current config, I've put 2001:1928:1::1 on both dc1 and em0. This appears to work acceptably. Putting it on only dc1 or only em0 provides ipv6 service to only that segment. Note that this is not true for IPv4 --- only dc1 has IPv4 addresses and they all work. My laptop makes for a good test. It has a GigE interface (bge0) and a wireless card (iwi0). Wireless is a dumb bridge connected to dc1. If em0 has the address (only), bge0 connected to the em0 segment works. bge0 connected to the dc1 segment or iwi0 (still dc1 segment) doesn't work. If dc1 (only) has the ipv6 address, bge0 connected to the em0 segment doesn't work, bge0 connected to the dc1 segment or iwi0 (also on the dc1 segment) works. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 06:37:37 2007 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 7200816A417 for ; Fri, 16 Nov 2007 06:37:37 +0000 (UTC) (envelope-from fox@verio.net) Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2.email.verio.net [129.250.36.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4EB9D13C458 for ; Fri, 16 Nov 2007 06:37:34 +0000 (UTC) (envelope-from fox@verio.net) Received: from [129.250.36.64] (helo=dfw-mmp4.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp id 1IsuPg-0001VB-U9 for freebsd-net@freebsd.org; Fri, 16 Nov 2007 06:10:48 +0000 Received: from [129.250.40.241] (helo=limbo.int.dllstx01.us.it.verio.net) by dfw-mmp4.email.verio.net with esmtp id 1IsuPg-0006SQ-Qp for freebsd-net@freebsd.org; Fri, 16 Nov 2007 06:10:48 +0000 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id 3387C8E296; Fri, 16 Nov 2007 00:10:48 -0600 (CST) Date: Fri, 16 Nov 2007 00:10:48 -0600 From: David DeSimone To: freebsd-net@freebsd.org Message-ID: <20071116061047.GA8361@verio.net> Mail-Followup-To: freebsd-net@freebsd.org References: <473C5593.4080407@tnetus.com> <20071116001429.GE1499@beaver.trit.net> <473D3258.9040203@tnetus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <473D3258.9040203@tnetus.com> Precedence: bulk User-Agent: Mutt/1.5.9i Subject: Re: Interface address sourced packets go thru default gateway on another interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2007 06:37:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Hawk wrote: > > I believe binding an IP's source address to an interface address > (instead of INADDR_ANY) is to make packets go out from *that* > interface, not the default gw. I'm afraid that's not how it works. In the absence of policy-routing options, packets are always routed ONLY by destination address. Binding to a particular interface only set's the source IP that will be attached to the packet, and will influence routing on the *return* trip of any replies. - -- David DeSimone == Network Admin == fox@verio.net "This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, dis- tribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you." --Lawyer Bot 6000 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFHPTRnFSrKRjX5eCoRAj4FAJ96YpEamhN7Cpg1tlv6kMaZsq/dnQCghfDW ZZ2MER+p404Eu21G4x6OK00= =Ppe1 -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 10:35:34 2007 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 E5CD616A417; Fri, 16 Nov 2007 10:35:34 +0000 (UTC) (envelope-from kmacy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BBD6713C455; Fri, 16 Nov 2007 10:35:34 +0000 (UTC) (envelope-from kmacy@FreeBSD.org) Received: from freefall.freebsd.org (kmacy@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id lAGAZYbs001436; Fri, 16 Nov 2007 10:35:34 GMT (envelope-from kmacy@freefall.freebsd.org) Received: (from kmacy@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id lAGAZYUR001432; Fri, 16 Nov 2007 10:35:34 GMT (envelope-from kmacy) Date: Fri, 16 Nov 2007 10:35:34 GMT Message-Id: <200711161035.lAGAZYUR001432@freefall.freebsd.org> To: kmacy@FreeBSD.org, freebsd-net@FreeBSD.org, thompsa@FreeBSD.org From: kmacy@FreeBSD.org Cc: Subject: Re: kern/103253: inconsistent behaviour in arp reply of a bridge 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, 16 Nov 2007 10:35:35 -0000 Synopsis: inconsistent behaviour in arp reply of a bridge Responsible-Changed-From-To: freebsd-net->thompsa Responsible-Changed-By: kmacy Responsible-Changed-When: Fri Nov 16 10:34:55 UTC 2007 Responsible-Changed-Why: Is this still an issue? http://www.freebsd.org/cgi/query-pr.cgi?pr=103253 From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 11:10:54 2007 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 91C5C16A420 for ; Fri, 16 Nov 2007 11:10:54 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4650513C43E for ; Fri, 16 Nov 2007 11:10:54 +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 F41824723B; Fri, 16 Nov 2007 06:10:46 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 16 Nov 2007 06:10:47 -0500 X-Sasl-enc: PlNfAR/bDk4ZV9+CJ0fLDkC9ljG31kHZA8K/YywBQkMl 1195211446 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 659B3E2E8; Fri, 16 Nov 2007 06:10:46 -0500 (EST) Message-ID: <473D7AB5.1040403@FreeBSD.org> Date: Fri, 16 Nov 2007 11:10:45 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Brian Hawk References: <473C5593.4080407@tnetus.com> <20071116001429.GE1499@beaver.trit.net> <473D3258.9040203@tnetus.com> In-Reply-To: <473D3258.9040203@tnetus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Dima Dorfman Subject: Re: Interface address sourced packets go thru default gateway on another interface 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, 16 Nov 2007 11:10:54 -0000 Brian Hawk wrote: > Then what would be the reason to bind a connection to a specific > source address? We do > ping -S A.B.C.D x.y.z.t > to make ping send packets to x.y.z.t over A.B.C.D's interface (and > source address) or > telnet -s A.B.C.D x.y.z.t > > I believe binding an IP's source address to an interface address > (instead of INADDR_ANY) is to make packets go out from *that* > interface, not the default gw. Nope, this has never been the case. Binding a socket to an address does just that -- it does NOT bind a socket to an interface. The source address selection during an accept() or bind() is chosen based on the address provided to the bind() call, or the address from which the SYN originated which your code is accept()-ing; the kernel will then choose the address 'nearest' to the node which sent the SYN for further communication, by doing a route lookup. During ip_output() the actual interface pointer lookup will take place based on the destination address. Then and only then is the actual interface selected. This is a set of behaviours which will have to change in netinet in order to support stuff like bind-to-interface, scoped addresses and the 169.254.0.0/16 link-local block correctly -- we SHOULD be looking at the address to which the socket is bound before doing anything (compare with Linux's SO_BINDTODEVICE option; which causes layer pollution and I would suggest should NOT be implemented in the same way in FreeBSD). As other contributors have suggested, if you really need source routing, use pf or similar for that. I believe ipf also supports route-to on the outbound. cheers, BMS From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 13:36:04 2007 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 B8DEE16A469 for ; Fri, 16 Nov 2007 13:36:04 +0000 (UTC) (envelope-from iaccounts@ibctech.ca) Received: from pearl.ibctech.ca (pearl.ibctech.ca [208.70.104.210]) by mx1.freebsd.org (Postfix) with ESMTP id 4573113C447 for ; Fri, 16 Nov 2007 13:36:04 +0000 (UTC) (envelope-from iaccounts@ibctech.ca) Received: (qmail 80287 invoked by uid 1002); 16 Nov 2007 13:35:58 -0000 Received: from iaccounts@ibctech.ca by pearl.ibctech.ca by uid 89 with qmail-scanner-1.22 (spamassassin: 2.64. Clear:RC:1(208.70.104.100):. Processed in 6.522785 secs); 16 Nov 2007 13:35:58 -0000 Received: from unknown (HELO ?192.168.30.110?) (steve@ibctech.ca@208.70.104.100) by pearl.ibctech.ca with (DHE-RSA-AES256-SHA encrypted) SMTP; 16 Nov 2007 13:35:51 -0000 Message-ID: <473D9CB9.9050005@ibctech.ca> Date: Fri, 16 Nov 2007 08:35:53 -0500 From: Steve Bertrand User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <473C5593.4080407@tnetus.com> <20071116001429.GE1499@beaver.trit.net> <473D3258.9040203@tnetus.com> <473D7AB5.1040403@FreeBSD.org> In-Reply-To: <473D7AB5.1040403@FreeBSD.org> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Brian Hawk , Dima Dorfman Subject: Re: Interface address sourced packets go thru default gateway on another interface 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, 16 Nov 2007 13:36:04 -0000 > As other contributors have suggested, if you really need source routing, > use pf or similar for that. I believe ipf also supports route-to on the > outbound. Another solutions would be that if there is only a known subset of networks sending you data over the leased line (such as a few /24's), then you can just statically route these blocks back over that connection. If not, as many others have said, it's policy based routing for you ;) Steve From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 15:27:25 2007 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 D82C716A418; Fri, 16 Nov 2007 15:27:25 +0000 (UTC) (envelope-from netch@segfault.kiev.ua) Received: from smartrelay.lucky.net (sivka.carrier.kiev.ua [193.193.193.101]) by mx1.freebsd.org (Postfix) with ESMTP id 4EFEE13C4AC; Fri, 16 Nov 2007 15:27:24 +0000 (UTC) (envelope-from netch@segfault.kiev.ua) Received: from segfault.kiev.ua (root@segfault.kiev.ua [193.193.193.4]) by smartrelay.lucky.net (smartrelay/Kilkenny_is_better) with ESMTP id lBGF8bTX006470; Fri, 16 Nov 2007 17:08:41 +0200 (EET) (envelope-from netch@segfault.kiev.ua) Received: from segfault.kiev.ua (netch@localhost.segfault.kiev.ua [127.0.0.1]) by segfault.kiev.ua (8.13.8/8.13.8/8.Who.Cares) with ESMTP id lAGF8PGH031035; Fri, 16 Nov 2007 17:08:25 +0200 (EET) (envelope-from netch@segfault.kiev.ua) Received: (from netch@localhost) by segfault.kiev.ua (8.13.8/8.13.8/Submit) id lAGF8PmM031032; Fri, 16 Nov 2007 17:08:25 +0200 (EET) (envelope-from netch) Date: Fri, 16 Nov 2007 17:08:25 +0200 From: Valentin Nechayev To: kmacy@FreeBSD.org Message-ID: <20071116150825.GG1108@netch.kiev.ua> References: <200711160240.lAG2e14u071457@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200711160240.lAG2e14u071457@freefall.freebsd.org> X-42: On Cc: freebsd-net@FreeBSD.org Subject: Re: kern/21998: [socket] [patch] ident only for outgoing connections X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: netch@netch.kiev.ua List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2007 15:27:25 -0000 Fri, Nov 16, 2007 at 02:40:01, kmacy wrote about "Re: kern/21998: [socket] [patch] ident only for outgoing connections": > Need to confirm that this issue still applies. Yes, nothing is changed (at least for versions known to me) > http://www.freebsd.org/cgi/query-pr.cgi?pr=21998 -netch- From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 15:56:22 2007 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 2169916A469 for ; Fri, 16 Nov 2007 15:56:22 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.freebsd.org (Postfix) with ESMTP id C515813C459 for ; Fri, 16 Nov 2007 15:56:21 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id C2EC97B4C for ; Fri, 16 Nov 2007 18:37:44 +0300 (MSK) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by relay0.rambler.ru (Postfix) with ESMTP id A21657C7E for ; Fri, 16 Nov 2007 18:37:44 +0300 (MSK) Date: Fri, 16 Nov 2007 18:40:19 +0300 From: Igor Sysoev To: freebsd-net@freebsd.org Message-ID: <20071116154019.GE93422@rambler-co.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="i0/AhcQY5QxfSsSZ" Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Subject: bge loader tunables 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, 16 Nov 2007 15:56:22 -0000 --i0/AhcQY5QxfSsSZ Content-Type: text/plain; charset=koi8-r Content-Disposition: inline The attached patch creates the following bge loader tunables: hw.bge.rxd=512 Number of standard receive descriptors allocated by the driver. The default value is 256. The maximum value is 512. hw.bge.rx_int_delay=500 This value delays the generation of receive interrupts in microseconds. The default value is 150 microseconds. hw.bge.tx_int_delay=500 This value delays the generation of transmit interrupts in microseconds. The default value is 150 microseconds. hw.bge.rx_coal_desc=64 This value delays the generation of receive interrupts until specified number of packets will be received. The default value is 10. hw.bge.tx_coal_desc=128 This value delays the generation of transmit interrupts until specified number of packets will be transmited. The default value is 10. -- Igor Sysoev http://sysoev.ru/en/ --i0/AhcQY5QxfSsSZ Content-Type: text/x-diff; charset=koi8-r Content-Disposition: attachment; filename="bge.7.patch" --- sys/dev/bge/if_bge.c 2007-09-30 15:05:14.000000000 +0400 +++ sys/dev/bge/if_bge.c 2007-11-15 23:01:57.000000000 +0300 @@ -426,8 +426,18 @@ DRIVER_MODULE(miibus, bge, miibus_driver, miibus_devclass, 0, 0); static int bge_allow_asf = 0; +static int bge_rxd = BGE_SSLOTS; +static int bge_rx_coal_ticks = 150; +static int bge_tx_coal_ticks = 150; +static int bge_rx_max_coal_bds = 10; +static int bge_tx_max_coal_bds = 10; TUNABLE_INT("hw.bge.allow_asf", &bge_allow_asf); +TUNABLE_INT("hw.bge.rxd", &bge_rxd); +TUNABLE_INT("hw.bge.rx_int_delay", &bge_rx_coal_ticks); +TUNABLE_INT("hw.bge.tx_int_delay", &bge_tx_coal_ticks); +TUNABLE_INT("hw.bge.rx_coal_desc", &bge_rx_max_coal_bds); +TUNABLE_INT("hw.bge.tx_coal_desc", &bge_tx_max_coal_bds); SYSCTL_NODE(_hw, OID_AUTO, bge, CTLFLAG_RD, 0, "BGE driver parameters"); SYSCTL_INT(_hw_bge, OID_AUTO, allow_asf, CTLFLAG_RD, &bge_allow_asf, 0, @@ -877,10 +887,10 @@ { int i; - for (i = 0; i < BGE_SSLOTS; i++) { + for (i = 0; i < bge_rxd; i++) { if (bge_newbuf_std(sc, i, NULL) == ENOBUFS) return (ENOBUFS); - }; + } bus_dmamap_sync(sc->bge_cdata.bge_rx_std_ring_tag, sc->bge_cdata.bge_rx_std_ring_map, @@ -2453,10 +2463,10 @@ /* Set default tuneable values. */ sc->bge_stat_ticks = BGE_TICKS_PER_SEC; - sc->bge_rx_coal_ticks = 150; - sc->bge_tx_coal_ticks = 150; - sc->bge_rx_max_coal_bds = 10; - sc->bge_tx_max_coal_bds = 10; + sc->bge_rx_coal_ticks = bge_rx_coal_ticks; + sc->bge_tx_coal_ticks = bge_tx_coal_ticks; + sc->bge_rx_max_coal_bds = bge_rx_max_coal_bds; + sc->bge_tx_max_coal_bds = bge_tx_max_coal_bds; /* Set up ifnet structure */ ifp = sc->bge_ifp = if_alloc(IFT_ETHER); --i0/AhcQY5QxfSsSZ-- From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 16:58:19 2007 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 8E49C16A417 for ; Fri, 16 Nov 2007 16:58:19 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.231]) by mx1.freebsd.org (Postfix) with ESMTP id 3E45413C45D for ; Fri, 16 Nov 2007 16:58:19 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so888009nzf for ; Fri, 16 Nov 2007 08:58:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=TjLTt96vTou1sdpIE1Ym2AQ+Dhldtg6NkTuuopglJGs=; b=dyIPUJze43do0+hfYOPwb3tvABOLyPV37wkUlfkkTvzAn3d8VzPmkKea7M7thCladHJczTIdKthlpExIn2v4n3YaCvm1w27qsZWrshUeoZQDOSSlECYl9d96U9aLQk4JkzJzPh6cvkaiJXGUAqxF+Rjz9iDqdewugDhGEedfeAI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SOWJhKIyl3KkC+hDqInB/VtXxGA525yD1JxFl+k7VMdvvWSQHpdPwWHu+cjNI9XevMDignug44OlG67omhUoc4eNUVd6bLbk/t7ZmMGru/hwnpus9itk9eo5bQFVys2gQKQbyscxVbiqeqRJAhnJFdlBhnEpOgHqnvx23xZ3RrI= Received: by 10.115.90.1 with SMTP id s1mr213665wal.1195232289820; Fri, 16 Nov 2007 08:58:09 -0800 (PST) Received: by 10.114.13.15 with HTTP; Fri, 16 Nov 2007 08:58:09 -0800 (PST) Message-ID: Date: Fri, 16 Nov 2007 08:58:09 -0800 From: "Kip Macy" To: netch@netch.kiev.ua In-Reply-To: <20071116150825.GG1108@netch.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200711160240.lAG2e14u071457@freefall.freebsd.org> <20071116150825.GG1108@netch.kiev.ua> Cc: freebsd-net@freebsd.org, kmacy@freebsd.org Subject: Re: kern/21998: [socket] [patch] ident only for outgoing connections 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, 16 Nov 2007 16:58:19 -0000 On Nov 16, 2007 7:08 AM, Valentin Nechayev wrote: > Fri, Nov 16, 2007 at 02:40:01, kmacy wrote about "Re: kern/21998: [socket] [patch] ident only for outgoing connections": > > > Need to confirm that this issue still applies. > Yes, nothing is changed (at least for versions known to me) > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=21998 Ok, I've taken it. > > > -netch- > From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 21:00:34 2007 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 1FA6D16A476; Fri, 16 Nov 2007 21:00:34 +0000 (UTC) (envelope-from kmacy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DBFC013C502; Fri, 16 Nov 2007 21:00:33 +0000 (UTC) (envelope-from kmacy@FreeBSD.org) Received: from freefall.freebsd.org (kmacy@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id lAGL0XDb035825; Fri, 16 Nov 2007 21:00:33 GMT (envelope-from kmacy@freefall.freebsd.org) Received: (from kmacy@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id lAGL0X3R035821; Fri, 16 Nov 2007 21:00:33 GMT (envelope-from kmacy) Date: Fri, 16 Nov 2007 21:00:33 GMT Message-Id: <200711162100.lAGL0X3R035821@freefall.freebsd.org> To: kmacy@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: kmacy@FreeBSD.org Cc: Subject: Re: kern/117717: Kernel panic with Bittorrent client. 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, 16 Nov 2007 21:00:34 -0000 Synopsis: Kernel panic with Bittorrent client. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: kmacy Responsible-Changed-When: Fri Nov 16 21:00:21 UTC 2007 Responsible-Changed-Why: Networking bug. http://www.freebsd.org/cgi/query-pr.cgi?pr=117717 From owner-freebsd-net@FreeBSD.ORG Fri Nov 16 21:31:05 2007 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 7C11B16A46C for ; Fri, 16 Nov 2007 21:31:05 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id 1A14E13C467 for ; Fri, 16 Nov 2007 21:31:04 +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 mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lAGLUw16003186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Nov 2007 08:31:02 +1100 Date: Sat, 17 Nov 2007 08:30:58 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Igor Sysoev In-Reply-To: <20071116154019.GE93422@rambler-co.ru> Message-ID: <20071117065908.T65479@delplex.bde.org> References: <20071116154019.GE93422@rambler-co.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org Subject: Re: bge loader tunables 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, 16 Nov 2007 21:31:05 -0000 On Fri, 16 Nov 2007, Igor Sysoev wrote: > The attached patch creates the following bge loader tunables: I plan to commit old work to do this using sysctls. Tunables are harder to use and aren't needed since changes to the defaults aren't needed for booting. I also implemented dynamic tuning for rx coal parameters so that the sysctls are mostly not needed. Ask for patches if you want to test this extensively. > hw.bge.rxd=512 > > Number of standard receive descriptors allocated by the driver. > The default value is 256. The maximum value is 512. I always use 512 for this. The corresponding value for jumbo buffers is hard-coded (JSLOTS exists to tune the value at config time, like SSLOTS does for this, but is no longer used). Only machines with a small amount of memory should care about the wastage from always allocating the max number of descriptors. > hw.bge.rx_int_delay=500 > > This value delays the generation of receive interrupts in microseconds. > The default value is 150 microseconds. This is a good default. I normally use 100 (goes with dynamic tuning to limit the rx interrupt rate to 10 kHz). > hw.bge.tx_int_delay=500 > > This value delays the generation of transmit interrupts in microseconds. > The default value is 150 microseconds. I use 1 second. Infinity works right, except it wastes mbufs when the tx is idle for a long time. > hw.bge.rx_coal_desc=64 > > This value delays the generation of receive interrupts until specified > number of packets will be received. The default value is 10. 64 is a good default. 10 is a bad default (it optimizes too much for latency at a cost of efficiency to be good). I use 1 when optimizing for latency. Dynamic tuning sets this to a value suitable for limiting the rx interrupt rate to a specified frequency (10 kHz is a good limit). > hw.bge.tx_coal_desc=128 > > This value delays the generation of transmit interrupts until specified > number of packets will be transmited. The default value is 10. 128 is a good default. I use 384. There are few latency issues here, so the default of 10 mainly costs efficiency. Bruce From owner-freebsd-net@FreeBSD.ORG Sat Nov 17 07:08:28 2007 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 2185616A46C for ; Sat, 17 Nov 2007 07:08:28 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.freebsd.org (Postfix) with ESMTP id CFD0713C45D for ; Sat, 17 Nov 2007 07:08:26 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 56E976FDF; Sat, 17 Nov 2007 10:08:19 +0300 (MSK) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by relay0.rambler.ru (Postfix) with ESMTP id 3447B6FDC; Sat, 17 Nov 2007 10:08:19 +0300 (MSK) Date: Sat, 17 Nov 2007 10:10:53 +0300 From: Igor Sysoev To: Bruce Evans Message-ID: <20071117071053.GA18091@rambler-co.ru> References: <20071116154019.GE93422@rambler-co.ru> <20071117065908.T65479@delplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20071117065908.T65479@delplex.bde.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: freebsd-net@FreeBSD.org Subject: Re: bge loader tunables 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, 17 Nov 2007 07:08:28 -0000 On Sat, Nov 17, 2007 at 08:30:58AM +1100, Bruce Evans wrote: > On Fri, 16 Nov 2007, Igor Sysoev wrote: > > >The attached patch creates the following bge loader tunables: > > I plan to commit old work to do this using sysctls. Tunables are > harder to use and aren't needed since changes to the defaults aren't > needed for booting. I also implemented dynamic tuning for rx coal > parameters so that the sysctls are mostly not needed. Ask for patches > if you want to test this extensively. Yes, I can test your patches on 6.2 and 7.0. Now bge set the coalescing parameters at attach time. Do the sysctl's allow to change them on-the-fly ? How does rx dynamic tuning work ? Could it be turned off ? > >hw.bge.rxd=512 > > > >Number of standard receive descriptors allocated by the driver. > >The default value is 256. The maximum value is 512. > > I always use 512 for this. The corresponding value for jumbo buffers > is hard-coded (JSLOTS exists to tune the value at config time, like > SSLOTS does for this, but is no longer used). Only machines with a > small amount of memory should care about the wastage from always > allocating the max number of descriptors. I agree: the default jumbo rx ring takes 256*9216=2.3M, while maximum standard rx ring takes 512*2048=1M, nevertheless it is limited to 256*2048=512K. > >hw.bge.rx_int_delay=500 > > > >This value delays the generation of receive interrupts in microseconds. > >The default value is 150 microseconds. > > This is a good default. I normally use 100 (goes with dynamic tuning to > limit the rx interrupt rate to 10 kHz). > > >hw.bge.tx_int_delay=500 > > > >This value delays the generation of transmit interrupts in microseconds. > >The default value is 150 microseconds. > > I use 1 second. Infinity works right, except it wastes mbufs when the > tx is idle for a long time. It seems 1 second is good for me: I use sendfile() and lot of mbufs clusters: kern.ipc.nmbclusters=196608 > >hw.bge.rx_coal_desc=64 > > > >This value delays the generation of receive interrupts until specified > >number of packets will be received. The default value is 10. > > 64 is a good default. 10 is a bad default (it optimizes too much for > latency at a cost of efficiency to be good). I use 1 when optimizing > for latency. Dynamic tuning sets this to a value suitable for limiting > the rx interrupt rate to a specified frequency (10 kHz is a good limit). > > >hw.bge.tx_coal_desc=128 > > > >This value delays the generation of transmit interrupts until specified > >number of packets will be transmited. The default value is 10. > > 128 is a good default. I use 384. There are few latency issues here, so > the default of 10 mainly costs efficiency. Does 384 not delay tx if there is shortage of free tx descriptors ? -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Sat Nov 17 10:14:02 2007 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 17E1116A419 for ; Sat, 17 Nov 2007 10:14:02 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail15.syd.optusnet.com.au (mail15.syd.optusnet.com.au [211.29.132.196]) by mx1.freebsd.org (Postfix) with ESMTP id 1AA1613C442 for ; Sat, 17 Nov 2007 10:14:00 +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 mail15.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lAHADoNm025252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Nov 2007 21:13:56 +1100 Date: Sat, 17 Nov 2007 21:13:50 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Igor Sysoev In-Reply-To: <20071117071053.GA18091@rambler-co.ru> Message-ID: <20071117194615.L67319@delplex.bde.org> References: <20071116154019.GE93422@rambler-co.ru> <20071117065908.T65479@delplex.bde.org> <20071117071053.GA18091@rambler-co.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org Subject: Re: bge loader tunables 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, 17 Nov 2007 10:14:02 -0000 On Sat, 17 Nov 2007, Igor Sysoev wrote: > On Sat, Nov 17, 2007 at 08:30:58AM +1100, Bruce Evans wrote: > >> On Fri, 16 Nov 2007, Igor Sysoev wrote: >> >>> The attached patch creates the following bge loader tunables: >> >> I plan to commit old work to do this using sysctls. Tunables are >> harder to use and aren't needed since changes to the defaults aren't >> needed for booting. I also implemented dynamic tuning for rx coal >> parameters so that the sysctls are mostly not needed. Ask for patches >> if you want to test this extensively. > > Yes, I can test your patches on 6.2 and 7.0. > Now bge set the coalescing parameters at attach time. > Do the sysctl's allow to change them on-the-fly ? > How does rx dynamic tuning work ? > Could it be turned off ? OK, the patch is enclosed at the end, in 2 versions: - all my patches for bge (with lots of debugging cruft and half-baked fixes for 5705+ sysctls. - edited version with only the coalescing parameter changes. I haven't used it under 6.2, but have used a similar version in ~5.2, and it should work in 6.2 except for the 5705+ sysctl fixes. bge actually sets parameters at init time, and it initializes whenever the link is brought back up, so the parameters can be changed using "ifconfig bgeN down up". Several network drivers have interrupt moderation parameters that can be changed in this way, but it is painful to change the link status like that, so I have a sysctl dev.bge.N.program_coal to apply the current parameters to the hardware. The other sysctls to change the parameters don't apply immediately, except the one for the rx tuning max interrupt rate, since applying the changed parameters to the hardware takes more code than a SYSCTL_INT(), and it is sometimes necessary to change all the parameters together atomically. Dynamic tuning works by monitoring the current rx packet rate and increasing the active rx_max_coal_bds so that the ratio / rx_max_coal_bds is usually <= the specified max rx interrupt rate. rx_coal_ticks is set to the constant value of the inverse of the specified max rx interrupt rate (in ticks) on transition to dynamic mode but IIRC is not changed when the dynamic rate is changed (not always changing it automatically allows adjusting it independently of the rate but is often not what is wanted). The transition has some bias towards lower latency over too many interrupts, so that short bursts don't increase the latency. I think this simple algorithm is good enough provided the load (in rx packets/second) doesn't oscillate rapidly. Dynamic tuning requires efficient reprogramming of at least one of the hardware coal registers so that the tuning can respond rapidly to changes. I have 2 methods for this: - bge_careful_coal = 1 avoids using uses a potentially very long busy-wait loop in the interrupt handler by giving up on reprogramming the host coalescing engine (HCE) if the HCE seems to be busy. Docs seem to require waiting for up to several milliseconds for the HCE to stablilize, and it is not clear if it is possible for the HCE to never stabilize because packets are streaming in. (I don't have proper docs.) This seems to always work (the HCE is never busy) for rx_max_coal_bds, but something near here didn't work for changing rx_coal_ticks in an old version. - bge_careful_coal = 0 avoids the loop by writing to the rx_max_coal_bds register without waiting for the HCE. This seems to work too. It isn't critical for the HCE to see the change immediately or even for it to be seen at all (missed changes might do more than give a huge interrupt rate for too long), but it is important for the change to not break the engine. There is no sysctl for this of for some other hackish parameters. The source must be edited to change this from 1 to 0. Dynamic tuning is turned off by setting the dynamic max interrupt frequency to 0. Then rx_coal_ticks is reset to 150, and the active rx_max_coal_bds is restored to the static value. >>> hw.bge.tx_coal_desc=128 >>> >>> This value delays the generation of transmit interrupts until specified >>> number of packets will be transmited. The default value is 10. >> >> 128 is a good default. I use 384. There are few latency issues here, so >> the default of 10 mainly costs efficiency. > > Does 384 not delay tx if there is shortage of free tx descriptors ? No, it just increases the risk of the tx running dry by possibly not interrupting until there are only a few tx descriptors remaining in the hardware tx queue. Under load, the interrupt handler and/or bge_start() normally refills the queue to length 496 (512 less 16 for safety), and an interrupt arrives 384 descriptors later when the queue length has been reduced to 112. (My debugging sysctls show this behaviour clearly.) Then the interrupt must be handled (at least partially) within 112 descriptor times to avoid the tx running dry. This handling is usually possible. Even 480 works OK, but the throughput drops noticeably near that value. Under lighter loads, the queue is not completely refilled, but there is little chance of the tx running dry since OACTIVE is not set (the queue could only run dry despite there being data to be sent if unrelated system load prevents threads from running enough to top up the queue). Complete patch: --- % Index: if_bge.c % =================================================================== % RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v % retrieving revision 1.198 % diff -u -2 -r1.198 if_bge.c % --- if_bge.c 30 Sep 2007 11:05:14 -0000 1.198 % +++ if_bge.c 8 Nov 2007 16:01:49 -0000 % @@ -1,2 +1,10 @@ % +int bge_careful_coal = 1; % +int bge_qlen = 1; % +int bge_errsrc = 0x17; % +int bge_rx_repl = 64; % +int bge_coal_writes; % +int bge_coal_write_fails; % +int bge_polling_trust_statusword = 0; % + % /*- % * Copyright (c) 2001 Wind River Systems % @@ -386,4 +394,5 @@ % * traps on certain architectures. % */ % +#define BGE_REGISTER_DEBUG % #ifdef BGE_REGISTER_DEBUG % static int bge_sysctl_debug_info(SYSCTL_HANDLER_ARGS); % @@ -427,4 +436,5 @@ % % static int bge_allow_asf = 1; % +static int bge_return_ring_cnt = BGE_RETURN_RING_CNT; /* XXX global. */ % % TUNABLE_INT("hw.bge.allow_asf", &bge_allow_asf); % @@ -867,10 +877,4 @@ % } % % -/* % - * The standard receive ring has 512 entries in it. At 2K per mbuf cluster, % - * that's 1MB or memory, which is a lot. For now, we fill only the first % - * 256 ring entries and hope that our CPU is fast enough to keep up with % - * the NIC. % - */ % static int % bge_init_rx_ring_std(struct bge_softc *sc) % @@ -878,8 +882,8 @@ % int i; % % - for (i = 0; i < BGE_SSLOTS; i++) { % + for (i = 0; i < BGE_STD_RX_RING_CNT; i++) { % if (bge_newbuf_std(sc, i, NULL) == ENOBUFS) % return (ENOBUFS); % - }; % + } % % bus_dmamap_sync(sc->bge_cdata.bge_rx_std_ring_tag, % @@ -922,5 +926,5 @@ % if (bge_newbuf_jumbo(sc, i, NULL) == ENOBUFS) % return (ENOBUFS); % - }; % + } % % bus_dmamap_sync(sc->bge_cdata.bge_rx_jumbo_ring_tag, % @@ -1426,5 +1430,5 @@ % val = 8; % else % - val = BGE_STD_RX_RING_CNT / 8; % + val = BGE_STD_RX_RING_CNT / 8, bge_rx_repl; % CSR_WRITE_4(sc, BGE_RBDI_STD_REPL_THRESH, val); % CSR_WRITE_4(sc, BGE_RBDI_JUMBO_REPL_THRESH, BGE_JUMBO_RX_RING_CNT/8); % @@ -1530,4 +1534,11 @@ % % /* Set up host coalescing defaults */ % + if (sc->bge_dyncoal_max_intr_freq != 0) { % + sc->bge_dyncoal_scale = ((uint64_t)1 << 24) / % + sc->bge_dyncoal_max_intr_freq; % + sc->bge_rx_coal_ticks = BGE_TICKS_PER_SEC / % + sc->bge_dyncoal_max_intr_freq; % + } else % + sc->bge_rx_coal_ticks = 150; % CSR_WRITE_4(sc, BGE_HCC_RX_COAL_TICKS, sc->bge_rx_coal_ticks); % CSR_WRITE_4(sc, BGE_HCC_TX_COAL_TICKS, sc->bge_tx_coal_ticks); % @@ -2226,4 +2237,53 @@ % % static int % +bge_sysctl_program_coal(SYSCTL_HANDLER_ARGS) % +{ % + struct bge_softc *sc; % + int error, i, val; % + % + val = 0; % + error = sysctl_handle_int(oidp, &val, 0, req); % + if (error != 0 || req->newptr == NULL) % + return (error); % + sc = arg1; % + BGE_LOCK(sc); % + % + /* XXX cut from bge_blockinit(): */ % + % + /* Disable host coalescing until we get it set up */ % + CSR_WRITE_4(sc, BGE_HCC_MODE, 0x00000000); % + % + /* Poll to make sure it's shut down. */ % + for (i = 0; i < BGE_TIMEOUT; i++) { % + if (!(CSR_READ_4(sc, BGE_HCC_MODE) & BGE_HCCMODE_ENABLE)) % + break; % + DELAY(10); % + } % + % + if (i == BGE_TIMEOUT) { % + device_printf(sc->bge_dev, % + "host coalescing engine failed to idle\n"); % + CSR_WRITE_4(sc, BGE_HCC_MODE, BGE_HCCMODE_ENABLE); % + BGE_UNLOCK(sc); % + return (ENXIO); % + } % + % + /* Set up host coalescing defaults */ % + if (sc->bge_dyncoal_max_intr_freq != 0) % + sc->bge_dyncoal_scale = ((uint64_t)1 << 24) / % + sc->bge_dyncoal_max_intr_freq; % + CSR_WRITE_4(sc, BGE_HCC_RX_COAL_TICKS, sc->bge_rx_coal_ticks); % + CSR_WRITE_4(sc, BGE_HCC_TX_COAL_TICKS, sc->bge_tx_coal_ticks); % + CSR_WRITE_4(sc, BGE_HCC_RX_MAX_COAL_BDS, sc->bge_rx_max_coal_bds); % + CSR_WRITE_4(sc, BGE_HCC_TX_MAX_COAL_BDS, sc->bge_tx_max_coal_bds); % + % + /* Turn on host coalescing state machine */ % + CSR_WRITE_4(sc, BGE_HCC_MODE, BGE_HCCMODE_ENABLE); % + % + BGE_UNLOCK(sc); % + return (0); % +} % + % +static int % bge_attach(device_t dev) % { % @@ -2444,4 +2504,5 @@ % else % sc->bge_return_ring_cnt = BGE_RETURN_RING_CNT; % + bge_return_ring_cnt = sc->bge_return_ring_cnt; /* XXX */ % % if (bge_dma_alloc(dev)) { % @@ -2454,8 +2515,8 @@ % /* Set default tuneable values. */ % sc->bge_stat_ticks = BGE_TICKS_PER_SEC; % - sc->bge_rx_coal_ticks = 150; % - sc->bge_tx_coal_ticks = 150; % - sc->bge_rx_max_coal_bds = 10; % - sc->bge_tx_max_coal_bds = 10; % + sc->bge_dyncoal_max_intr_freq = 10000; % + sc->bge_tx_coal_ticks = 1000000; % + sc->bge_rx_max_coal_bds = 128; % + sc->bge_tx_max_coal_bds = BGE_TX_RING_CNT * 3 / 4; % % /* Set up ifnet structure */ % @@ -2473,5 +2534,9 @@ % ifp->if_init = bge_init; % ifp->if_mtu = ETHERMTU; % - ifp->if_snd.ifq_drv_maxlen = BGE_TX_RING_CNT - 1; % + if (bge_qlen & 1) % + ifp->if_snd.ifq_drv_maxlen = BGE_TX_RING_CNT + % + imax(2 * tick, 10000) / 4; % + else % + ifp->if_snd.ifq_drv_maxlen = BGE_TX_RING_CNT - 1; % IFQ_SET_MAXLEN(&ifp->if_snd, ifp->if_snd.ifq_drv_maxlen); % IFQ_SET_READY(&ifp->if_snd); % @@ -2861,4 +2926,55 @@ % } % % +struct bgrstats { % + struct timeval enter; % + struct timeval exit; % + int cnt0; % + int cnt1; % +}; % + % +/* XXX globals without global locking, so don't enable for multiple bge's. */ % + % +static struct bgrstats bgrs[1024]; % + % +static int bgrse; % +SYSCTL_INT(_debug, OID_AUTO, bgrse, CTLFLAG_RW, % + &bgrse, 0, "bge rx stats enable"); % + % +static int bgrso; % +SYSCTL_INT(_debug, OID_AUTO, bgrso, CTLFLAG_RW, % + &bgrso, 0, "bge rx stats offset"); % + % +static int % +sysctl_bgrs(SYSCTL_HANDLER_ARGS) % +{ % + size_t len; % + int error, i, max; % + char buf[256]; % + % + for (i = 1, max = sizeof(bgrs) / sizeof(bgrs[0]); i < max; i++) { % + len = sprintf(buf, % + "%4ld %10ld.%06ld %3d %3ld %3d %10ld.%06ld %3d\n", % + (bgrs[i].enter.tv_sec - bgrs[i - 1].exit.tv_sec) * 1000000 + % + bgrs[i].enter.tv_usec - bgrs[i - 1].exit.tv_usec, % + (long)bgrs[i].enter.tv_sec, bgrs[i].enter.tv_usec, % + bgrs[i].cnt0, % + (bgrs[i].exit.tv_sec - bgrs[i].enter.tv_sec) * 1000000 + % + bgrs[i].exit.tv_usec - bgrs[i].enter.tv_usec, % + (bgrs[i].cnt1 - bgrs[i].cnt0 + bge_return_ring_cnt) % % + bge_return_ring_cnt, % + (long)bgrs[i].exit.tv_sec, bgrs[i].exit.tv_usec, % + bgrs[i].cnt1); % + if (i == max - 1) % + buf[len - 1] = '\0'; % + error = SYSCTL_OUT(req, buf, len); % + if (error != 0) % + return (error); % + } % + return (0); % +} % + % +SYSCTL_PROC(_debug, OID_AUTO, bgrs, CTLTYPE_STRING | CTLFLAG_RD, % + 0, 0, sysctl_bgrs, "A", "bge rx stats"); % + % /* % * Frame reception handling. This is called if there's a frame % @@ -2883,4 +2999,9 @@ % return; % % + if (bgrse) { % + microtime(&bgrs[bgrso].enter); % + bgrs[bgrso].cnt0 = sc->bge_rx_saved_considx; % + } % + % ifp = sc->bge_ifp; % % @@ -2953,5 +3074,8 @@ % stdcnt++; % if (cur_rx->bge_flags & BGE_RXBDFLAG_ERROR) { % + if (bge_errsrc & 1) % ifp->if_ierrors++; % + if (bge_errsrc & 8) % + printf("errflag %#x\n", cur_rx->bge_error_flag); % bge_newbuf_std(sc, sc->bge_std, m); % continue; % @@ -2959,4 +3083,5 @@ % if (bge_newbuf_std(sc, sc->bge_std, % NULL) == ENOBUFS) { % + if (bge_errsrc & 2) % ifp->if_ierrors++; % bge_newbuf_std(sc, sc->bge_std, m); % @@ -3036,6 +3161,60 @@ % ifp->if_ierrors += CSR_READ_4(sc, BGE_RXLP_LOCSTAT_IFIN_DROPS); % #endif % + % + if (bgrse) { % + bgrs[bgrso].cnt1 = sc->bge_rx_saved_considx; % + microtime(&bgrs[bgrso].exit); % + bgrso = (bgrso + 1) % (sizeof(bgrs) / sizeof(bgrs[0])); % + } % } % % +struct bgtstats { % + struct timeval enter; % + struct timeval exit; % + int cnt0; % + int cnt1; % +}; % + % +static struct bgtstats bgts[1024]; % + % +static int bgtse; % +SYSCTL_INT(_debug, OID_AUTO, bgtse, CTLFLAG_RW, % + &bgtse, 0, "bge tx stats enable"); % + % +static int bgtso; % +SYSCTL_INT(_debug, OID_AUTO, bgtso, CTLFLAG_RW, % + &bgtso, 0, "bge tx stats offset"); % + % +static int % +sysctl_bgts(SYSCTL_HANDLER_ARGS) % +{ % + size_t len; % + int error, i, max; % + char buf[256]; % + % + for (i = 1, max = sizeof(bgts) / sizeof(bgts[0]); i < max; i++) { % + len = sprintf(buf, % + "%4ld %10ld.%06ld %3d %3ld %3d %10ld.%06ld %3d\n", % + (bgts[i].enter.tv_sec - bgts[i - 1].exit.tv_sec) * 1000000 + % + bgts[i].enter.tv_usec - bgts[i - 1].exit.tv_usec, % + (long)bgts[i].enter.tv_sec, bgts[i].enter.tv_usec, % + bgts[i].cnt0, % + (bgts[i].exit.tv_sec - bgts[i].enter.tv_sec) * 1000000 + % + bgts[i].exit.tv_usec - bgts[i].enter.tv_usec, % + bgts[i].cnt0 - bgts[i].cnt1, % + (long)bgts[i].exit.tv_sec, bgts[i].exit.tv_usec, % + bgts[i].cnt1); % + if (i == max - 1) % + buf[len - 1] = '\0'; % + error = SYSCTL_OUT(req, buf, len); % + if (error != 0) % + return (error); % + } % + return (0); % +} % + % +SYSCTL_PROC(_debug, OID_AUTO, bgts, CTLTYPE_STRING | CTLFLAG_RD, % + 0, 0, sysctl_bgts, "A", "bge tx stats"); % + % static void % bge_txeof(struct bge_softc *sc) % @@ -3051,4 +3230,9 @@ % return; % % + if (bgtse) { % + microtime(&bgts[bgtso].enter); % + bgts[bgtso].cnt0 = sc->bge_txcnt; % + } % + % ifp = sc->bge_ifp; % % @@ -3085,4 +3269,10 @@ % if (sc->bge_txcnt == 0) % sc->bge_timer = 0; % + % + if (bgtse) { % + bgts[bgtso].cnt1 = sc->bge_txcnt; % + microtime(&bgts[bgtso].exit); % + bgtso = (bgtso + 1) % (sizeof(bgts) / sizeof(bgts[0])); % + } % } % % @@ -3103,6 +3293,12 @@ % sc->bge_cdata.bge_status_map, BUS_DMASYNC_POSTREAD); % % + /* XXX possible race on switching from interrupt mode. */ % statusword = atomic_readandclear_32( % &sc->bge_ldata.bge_status_block->bge_status); % + if (cmd != POLL_AND_CHECK_STATUS && bge_polling_trust_statusword && % + (statusword & BGE_STATFLAG_UPDATED) == 0) { % + BGE_UNLOCK(sc); % + return; % + } % % bus_dmamap_sync(sc->bge_cdata.bge_status_tag, % @@ -3134,8 +3330,24 @@ % struct bge_softc *sc; % struct ifnet *ifp; % - uint32_t statusword; % + uint32_t macstatus, statusword; % % sc = xsc; % % + /* % + * Quick check without locking or syncing. Since we don't ack the % + * interrupt when we return early, the hardware will repeat the % + * interrupt if we lose a race here. Later we will clear the % + * status, and that needs at least the lock. % + * % + * XXX sc->bge_link_evt and maybe the BCM5700 errata are not handled. % + * % + * XXX there is no good order for this check relative to the % + * IFCAP_POLLING one. Since I don't believe in polling, I optimized % + * for !polling. % + */ % + statusword = sc->bge_ldata.bge_status_block->bge_status; % + if ((statusword & BGE_STATFLAG_UPDATED) == 0) % + return; % + % BGE_LOCK(sc); % % @@ -3174,5 +3386,5 @@ % * Do the mandatory PCI flush as well as get the link status. % */ % - statusword = CSR_READ_4(sc, BGE_MAC_STS) & BGE_MACSTAT_LINK_CHANGED; % + macstatus = CSR_READ_4(sc, BGE_MAC_STS); % % /* Make sure the descriptor ring indexes are coherent. */ % @@ -3184,13 +3396,56 @@ % if ((sc->bge_asicrev == BGE_ASICREV_BCM5700 && % sc->bge_chipid != BGE_CHIPID_BCM5700_B2) || % - statusword || sc->bge_link_evt) % + (macstatus & BGE_MACSTAT_LINK_CHANGED) || sc->bge_link_evt) % bge_link_upd(sc); % % if (ifp->if_drv_flags & IFF_DRV_RUNNING) { % - /* Check RX return ring producer/consumer. */ % bge_rxeof(sc); % - % - /* Check TX ring producer/consumer. */ % bge_txeof(sc); % + if (sc->bge_dyncoal_max_intr_freq != 0 && % + ++sc->bge_dyncoal_intrcnt == 16) { % + struct bintime bt; % + uint32_t dpi, pfrac, tfrac, xtime; % + % + binuptime(&bt); % + xtime = (bt.sec << 24) | (bt.frac >> 40); % + pfrac = (ifp->if_ipackets - sc->bge_dyncoal_ipackets) * % + sc->bge_dyncoal_scale; % + tfrac = xtime - sc->bge_dyncoal_xtime; % + sc->bge_dyncoal_rx_pps = % + (ifp->if_ipackets - sc->bge_dyncoal_ipackets) * % + ((uint64_t)1 << 24) / tfrac; % + dpi = pfrac / (tfrac | 2) + 1; % + if (dpi > sc->bge_rx_max_coal_bds) % + dpi = sc->bge_rx_max_coal_bds; % + if (dpi != sc->bge_dyncoal_rx_max_coal_bds) { % + if (bge_careful_coal) { % + CSR_WRITE_4(sc, BGE_HCC_MODE, 0); % + CSR_READ_4(sc, BGE_HCC_MODE); % + if ((CSR_READ_4(sc, BGE_HCC_MODE) & % + BGE_HCCMODE_ENABLE) == 0) { % + CSR_WRITE_4(sc, BGE_HCC_RX_MAX_COAL_BDS, % + dpi); % + sc->bge_dyncoal_rx_max_coal_bds = dpi; % + bge_coal_writes++; % + } else % + bge_coal_write_fails++; % + CSR_WRITE_4(sc, BGE_HCC_MODE, % + BGE_HCCMODE_ENABLE); % + } else { % + /* % + * XXX not waiting for the engine is needed % + * for efficiency since we reprogram it a % + * lot so as to react fast, and this seems % + * to work. However, similar reprogramming % + * of RX_COAL_TICKS doesn't work. % + */ % + CSR_WRITE_4(sc, BGE_HCC_RX_MAX_COAL_BDS, dpi); % + sc->bge_dyncoal_rx_max_coal_bds = dpi; % + } % + } % + sc->bge_dyncoal_xtime = xtime; % + sc->bge_dyncoal_intrcnt = 0; % + sc->bge_dyncoal_ipackets = ifp->if_ipackets; % + } % } % % @@ -3241,7 +3496,15 @@ % if ((sc->bge_flags & BGE_FLAG_TBI) == 0) { % mii = device_get_softc(sc->bge_miibus); % - /* Don't mess with the PHY in IPMI/ASF mode */ % - if (!((sc->bge_asf_mode & ASF_STACKUP) && (sc->bge_link))) % + /* Don't mess with the PHY unless link is down. */ % + if (!sc->bge_link) { % + if (bge_errsrc & 0x20) % + microtime(&bgrs[bgrso].enter); % + if (bge_errsrc & 0x10) % mii_tick(mii); % + if (bge_errsrc & 0x20) { % + microtime(&bgrs[bgrso].exit); % + bgrso = (bgrso + 1) % (sizeof(bgrs) / sizeof(bgrs[0])); % + } % + } % } else { % /* % @@ -3276,4 +3539,5 @@ % offsetof(struct bge_mac_stats_regs, etherStatsCollisions)); % % + if (bge_errsrc & 4) % ifp->if_ierrors += CSR_READ_4(sc, BGE_RXLP_LOCSTAT_IFIN_DROPS); % } % @@ -3298,4 +3562,5 @@ % % cnt = READ_STAT(sc, stats, ifInDiscards.bge_addr_lo); % + if (bge_errsrc & 4) % ifp->if_ierrors += (uint32_t)(cnt - sc->bge_rx_discards); % sc->bge_rx_discards = cnt; % @@ -4266,5 +4531,6 @@ % } % % -#define BGE_SYSCTL_STAT(sc, ctx, desc, parent, node, oid) \ % +/* XXX move this down and fix style bugs in it. */ % +#define BGE_SYSCTL_STAT_GEN(sc, ctx, desc, parent, node, oid) \ % SYSCTL_ADD_PROC(ctx, parent, OID_AUTO, oid, CTLTYPE_UINT|CTLFLAG_RD, \ % sc, offsetof(struct bge_stats, node), bge_sysctl_stats, "IU", \ % @@ -4281,4 +4547,27 @@ % children = SYSCTL_CHILDREN(device_get_sysctl_tree(sc->bge_dev)); % % + SYSCTL_ADD_PROC(ctx, children, OID_AUTO, "program_coal", % + CTLTYPE_INT | CTLFLAG_RW, % + sc, 0, bge_sysctl_program_coal, "I", % + "program bge coalescence values"); % + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "rx_coal_ticks", CTLFLAG_RW, % + &sc->bge_rx_coal_ticks, 0, ""); % + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "tx_coal_ticks", CTLFLAG_RW, % + &sc->bge_tx_coal_ticks, 0, ""); % + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "rx_max_coal_bds", CTLFLAG_RW, % + &sc->bge_rx_max_coal_bds, 0, ""); % + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "tx_max_coal_bds", CTLFLAG_RW, % + &sc->bge_tx_max_coal_bds, 0, ""); % + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "dyncoal_max_intr_freq", % + CTLFLAG_RW, % + &sc->bge_dyncoal_max_intr_freq, 0, ""); % + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "dyncoal_rx_max_coal_bds", % + CTLFLAG_RD, % + &sc->bge_dyncoal_rx_max_coal_bds, 0, ""); % + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "dyncoal_rx_pps", CTLFLAG_RD, % + &sc->bge_dyncoal_rx_pps, 0, ""); % + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "dyncoal_scale", CTLFLAG_RD, % + &sc->bge_dyncoal_scale, 0, ""); % + % #ifdef BGE_REGISTER_DEBUG % SYSCTL_ADD_PROC(ctx, children, OID_AUTO, "debug_info", % @@ -4299,4 +4588,7 @@ % NULL, "BGE Statistics"); % schildren = children = SYSCTL_CHILDREN(tree); % + /* Most of these seem to be unavailable on 5705+. */ % +if (!BGE_IS_5705_PLUS(sc)) { % +#define BGE_SYSCTL_STAT BGE_SYSCTL_STAT_GEN % BGE_SYSCTL_STAT(sc, ctx, "Frames Dropped Due To Filters", % children, COSFramesDroppedDueToFilters, % @@ -4308,4 +4600,8 @@ % BGE_SYSCTL_STAT(sc, ctx, "NIC No More RX Buffer Descriptors", % children, nicNoMoreRxBDs, "NoMoreRxBDs"); % + /* % + * The next one seems to be in BGE_RXLP_LOCSTAT_IFIN_DROPS for % + * the 5705+ case -- bge_stats_update_regs() uses this. % + */ % BGE_SYSCTL_STAT(sc, ctx, "Discarded Input Frames", % children, ifInDiscards, "InputDiscards"); % @@ -4330,86 +4626,126 @@ % BGE_SYSCTL_STAT(sc, ctx, "NIC Send Threshold Hit", % children, nicSendThresholdHit, "SendThresholdHit"); % +} % % tree = SYSCTL_ADD_NODE(ctx, schildren, OID_AUTO, "rx", CTLFLAG_RD, % NULL, "BGE RX Statistics"); % children = SYSCTL_CHILDREN(tree); % + __asm("# label for testing ifHCInOctets"); % + /* % + * Most rx stats are available for the 5705+case, but in a % + * different layout and with different semantics (32 bit registers % + * holding 12 (?) bit values which are reset on write instead of % + * 64-bit registers). We only handle the layout differences, and % + * do that using extremely ugly macros. Resetting of the registers % + * currently makes this sysctl almost useless for the 5705+ ase. % + * % + * The mapping of registers into structs mostly just gets in the % + * way here. % + */ % +#define BGE_SYSCTL_STAT_RX(sc, ctx, desc, parent, node, oid) \ % + SYSCTL_ADD_PROC(ctx, parent, OID_AUTO, oid, \ % + CTLTYPE_UINT | CTLFLAG_RD, sc, \ % + BGE_IS_5705_PLUS(sc) ? \ % + offsetof(struct bge_mac_stats_regs, node) : \ % + offsetof(struct bge_stats, rxstats.node), \ % + bge_sysctl_stats, "IU", desc) % +#undef BGE_SYSCTL_STAT % +#define BGE_SYSCTL_STAT BGE_SYSCTL_STAT_RX % + % BGE_SYSCTL_STAT(sc, ctx, "Inbound Octets", % - children, rxstats.ifHCInOctets, "Octets"); % + children, ifHCInOctets, "Octets"); % BGE_SYSCTL_STAT(sc, ctx, "Fragments", % - children, rxstats.etherStatsFragments, "Fragments"); % + children, etherStatsFragments, "Fragments"); % BGE_SYSCTL_STAT(sc, ctx, "Inbound Unicast Packets", % - children, rxstats.ifHCInUcastPkts, "UcastPkts"); % + children, ifHCInUcastPkts, "UcastPkts"); % BGE_SYSCTL_STAT(sc, ctx, "Inbound Multicast Packets", % - children, rxstats.ifHCInMulticastPkts, "MulticastPkts"); % + children, ifHCInMulticastPkts, "MulticastPkts"); % BGE_SYSCTL_STAT(sc, ctx, "FCS Errors", % - children, rxstats.dot3StatsFCSErrors, "FCSErrors"); % + children, dot3StatsFCSErrors, "FCSErrors"); % BGE_SYSCTL_STAT(sc, ctx, "Alignment Errors", % - children, rxstats.dot3StatsAlignmentErrors, "AlignmentErrors"); % + children, dot3StatsAlignmentErrors, "AlignmentErrors"); % BGE_SYSCTL_STAT(sc, ctx, "XON Pause Frames Received", % - children, rxstats.xonPauseFramesReceived, "xonPauseFramesReceived"); % + children, xonPauseFramesReceived, "xonPauseFramesReceived"); % BGE_SYSCTL_STAT(sc, ctx, "XOFF Pause Frames Received", % - children, rxstats.xoffPauseFramesReceived, % - "xoffPauseFramesReceived"); % + children, xoffPauseFramesReceived, "xoffPauseFramesReceived"); % BGE_SYSCTL_STAT(sc, ctx, "MAC Control Frames Received", % - children, rxstats.macControlFramesReceived, % - "ControlFramesReceived"); % + children, macControlFramesReceived, "ControlFramesReceived"); % BGE_SYSCTL_STAT(sc, ctx, "XOFF State Entered", % - children, rxstats.xoffStateEntered, "xoffStateEntered"); % + children, xoffStateEntered, "xoffStateEntered"); % BGE_SYSCTL_STAT(sc, ctx, "Frames Too Long", % - children, rxstats.dot3StatsFramesTooLong, "FramesTooLong"); % + children, dot3StatsFramesTooLong, "FramesTooLong"); % BGE_SYSCTL_STAT(sc, ctx, "Jabbers", % - children, rxstats.etherStatsJabbers, "Jabbers"); % + children, etherStatsJabbers, "Jabbers"); % BGE_SYSCTL_STAT(sc, ctx, "Undersized Packets", % - children, rxstats.etherStatsUndersizePkts, "UndersizePkts"); % - BGE_SYSCTL_STAT(sc, ctx, "Inbound Range Length Errors", % + children, etherStatsUndersizePkts, "UndersizePkts"); % + /* The next 2 seem to be unavailable for the 5705 case. */ % +if (!BGE_IS_5705_PLUS(sc)) { % + BGE_SYSCTL_STAT_GEN(sc, ctx, "Inbound Range Length Errors", % children, rxstats.inRangeLengthError, "inRangeLengthError"); % - BGE_SYSCTL_STAT(sc, ctx, "Outbound Range Length Errors", % + BGE_SYSCTL_STAT_GEN(sc, ctx, "Outbound Range Length Errors", % children, rxstats.outRangeLengthError, "outRangeLengthError"); % +} % % tree = SYSCTL_ADD_NODE(ctx, schildren, OID_AUTO, "tx", CTLFLAG_RD, % NULL, "BGE TX Statistics"); % children = SYSCTL_CHILDREN(tree); % + __asm("# label for testing ifHCOutOctets"); % + /* % + * tx is like rx except the macro needs "txstats." instead of % + * ".rxstats" for the non-5705+ variant. Redefine it again % + * to get this. % + */ % +#define BGE_SYSCTL_STAT_TX(sc, ctx, desc, parent, node, oid) \ % + SYSCTL_ADD_PROC(ctx, parent, OID_AUTO, oid, \ % + CTLTYPE_UINT | CTLFLAG_RD, sc, \ % + BGE_IS_5705_PLUS(sc) ? \ % + offsetof(struct bge_mac_stats_regs, node) : \ % + offsetof(struct bge_stats, txstats.node), \ % + bge_sysctl_stats, "IU", desc) % +#undef BGE_SYSCTL_STAT % +#define BGE_SYSCTL_STAT BGE_SYSCTL_STAT_TX % + % BGE_SYSCTL_STAT(sc, ctx, "Outbound Octets", % - children, txstats.ifHCOutOctets, "Octets"); % + children, ifHCOutOctets, "Octets"); % BGE_SYSCTL_STAT(sc, ctx, "TX Collisions", % - children, txstats.etherStatsCollisions, "Collisions"); % + children, etherStatsCollisions, "Collisions"); % BGE_SYSCTL_STAT(sc, ctx, "XON Sent", % - children, txstats.outXonSent, "XonSent"); % + children, outXonSent, "XonSent"); % BGE_SYSCTL_STAT(sc, ctx, "XOFF Sent", % - children, txstats.outXoffSent, "XoffSent"); % - BGE_SYSCTL_STAT(sc, ctx, "Flow Control Done", % + children, outXoffSent, "XoffSent"); % +if (!BGE_IS_5705_PLUS(sc)) { % + BGE_SYSCTL_STAT_GEN(sc, ctx, "Flow Control Done", % children, txstats.flowControlDone, "flowControlDone"); % +} % BGE_SYSCTL_STAT(sc, ctx, "Internal MAC TX errors", % - children, txstats.dot3StatsInternalMacTransmitErrors, % + children, dot3StatsInternalMacTransmitErrors, % "InternalMacTransmitErrors"); % BGE_SYSCTL_STAT(sc, ctx, "Single Collision Frames", % - children, txstats.dot3StatsSingleCollisionFrames, % - "SingleCollisionFrames"); % + children, dot3StatsSingleCollisionFrames, "SingleCollisionFrames"); % BGE_SYSCTL_STAT(sc, ctx, "Multiple Collision Frames", % - children, txstats.dot3StatsMultipleCollisionFrames, % + children, dot3StatsMultipleCollisionFrames, % "MultipleCollisionFrames"); % BGE_SYSCTL_STAT(sc, ctx, "Deferred Transmissions", % - children, txstats.dot3StatsDeferredTransmissions, % - "DeferredTransmissions"); % + children, dot3StatsDeferredTransmissions, "DeferredTransmissions"); % BGE_SYSCTL_STAT(sc, ctx, "Excessive Collisions", % - children, txstats.dot3StatsExcessiveCollisions, % - "ExcessiveCollisions"); % + children, dot3StatsExcessiveCollisions, "ExcessiveCollisions"); % BGE_SYSCTL_STAT(sc, ctx, "Late Collisions", % - children, txstats.dot3StatsLateCollisions, % - "LateCollisions"); % + children, dot3StatsLateCollisions, "LateCollisions"); % BGE_SYSCTL_STAT(sc, ctx, "Outbound Unicast Packets", % - children, txstats.ifHCOutUcastPkts, "UcastPkts"); % + children, ifHCOutUcastPkts, "UcastPkts"); % BGE_SYSCTL_STAT(sc, ctx, "Outbound Multicast Packets", % - children, txstats.ifHCOutMulticastPkts, "MulticastPkts"); % + children, ifHCOutMulticastPkts, "MulticastPkts"); % BGE_SYSCTL_STAT(sc, ctx, "Outbound Broadcast Packets", % - children, txstats.ifHCOutBroadcastPkts, "BroadcastPkts"); % - BGE_SYSCTL_STAT(sc, ctx, "Carrier Sense Errors", % + children, ifHCOutBroadcastPkts, "BroadcastPkts"); % +if (!BGE_IS_5705_PLUS(sc)) { % + BGE_SYSCTL_STAT_GEN(sc, ctx, "Carrier Sense Errors", % children, txstats.dot3StatsCarrierSenseErrors, % "CarrierSenseErrors"); % - BGE_SYSCTL_STAT(sc, ctx, "Outbound Discards", % + BGE_SYSCTL_STAT_GEN(sc, ctx, "Outbound Discards", % children, txstats.ifOutDiscards, "Discards"); % - BGE_SYSCTL_STAT(sc, ctx, "Outbound Errors", % + BGE_SYSCTL_STAT_GEN(sc, ctx, "Outbound Errors", % children, txstats.ifOutErrors, "Errors"); % } % +} % % static int % @@ -4422,10 +4758,13 @@ % sc = (struct bge_softc *)arg1; % offset = arg2; % - if (BGE_IS_5705_PLUS(sc)) % + if (BGE_IS_5705_PLUS(sc)) { % base = BGE_MAC_STATS; % - else % + result = CSR_READ_4(sc, base + offset); % + } % + else { % base = BGE_MEMWIN_START + BGE_STATS_BLOCK; % - result = CSR_READ_4(sc, base + offset + offsetof(bge_hostaddr, % - bge_addr_lo)); % + result = CSR_READ_4(sc, base + offset + offsetof(bge_hostaddr, % + bge_addr_lo)); % + } % return (sysctl_handle_int(oidp, &result, 0, req)); % } % Index: if_bgereg.h % =================================================================== % RCS file: /home/ncvs/src/sys/dev/bge/if_bgereg.h,v % retrieving revision 1.73 % diff -u -2 -r1.73 if_bgereg.h % --- if_bgereg.h 22 May 2007 19:22:58 -0000 1.73 % +++ if_bgereg.h 23 May 2007 09:12:50 -0000 % @@ -2338,13 +2338,7 @@ % % /* % - * Memory management stuff. Note: the SSLOTS, MSLOTS and JSLOTS % - * values are tuneable. They control the actual amount of buffers % - * allocated for the standard, mini and jumbo receive rings. % + * Memory management stuff. % */ % % -#define BGE_SSLOTS 256 % -#define BGE_MSLOTS 256 % -#define BGE_JSLOTS 384 % - % #define BGE_JRAWLEN (BGE_JUMBO_FRAMELEN + ETHER_ALIGN) % #define BGE_JLEN (BGE_JRAWLEN + (sizeof(uint64_t) - \ % @@ -2504,4 +2498,11 @@ % uint32_t bge_tx_discards; % uint32_t bge_tx_collisions; % + int bge_dyncoal_intrcnt; % + u_long bge_dyncoal_ipackets; % + uint32_t bge_dyncoal_max_intr_freq; % + uint32_t bge_dyncoal_rx_max_coal_bds; % + uint32_t bge_dyncoal_rx_pps; % + uint32_t bge_dyncoal_scale; % + uint32_t bge_dyncoal_xtime; % #ifdef DEVICE_POLLING % int rxcycles; --- Edited version (may have deleted too much or too little): --- % Index: if_bge.c % =================================================================== % RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v % retrieving revision 1.198 % diff -u -2 -r1.198 if_bge.c % --- if_bge.c 30 Sep 2007 11:05:14 -0000 1.198 % +++ if_bge.c 8 Nov 2007 16:01:49 -0000 % @@ -1,2 +1,10 @@ % +int bge_careful_coal = 1; % +int bge_qlen = 1; % +int bge_errsrc = 0x17; % +int bge_rx_repl = 64; % +int bge_coal_writes; % +int bge_coal_write_fails; % +int bge_polling_trust_statusword = 0; % + % /*- % * Copyright (c) 2001 Wind River Systems % @@ -867,10 +877,4 @@ % } % % -/* % - * The standard receive ring has 512 entries in it. At 2K per mbuf cluster, % - * that's 1MB or memory, which is a lot. For now, we fill only the first % - * 256 ring entries and hope that our CPU is fast enough to keep up with % - * the NIC. % - */ % static int % bge_init_rx_ring_std(struct bge_softc *sc) % @@ -878,8 +882,8 @@ % int i; % % - for (i = 0; i < BGE_SSLOTS; i++) { % + for (i = 0; i < BGE_STD_RX_RING_CNT; i++) { % if (bge_newbuf_std(sc, i, NULL) == ENOBUFS) % return (ENOBUFS); % - }; % + } % % bus_dmamap_sync(sc->bge_cdata.bge_rx_std_ring_tag, % @@ -1530,4 +1534,11 @@ % % /* Set up host coalescing defaults */ % + if (sc->bge_dyncoal_max_intr_freq != 0) { % + sc->bge_dyncoal_scale = ((uint64_t)1 << 24) / % + sc->bge_dyncoal_max_intr_freq; % + sc->bge_rx_coal_ticks = BGE_TICKS_PER_SEC / % + sc->bge_dyncoal_max_intr_freq; % + } else % + sc->bge_rx_coal_ticks = 150; % CSR_WRITE_4(sc, BGE_HCC_RX_COAL_TICKS, sc->bge_rx_coal_ticks); % CSR_WRITE_4(sc, BGE_HCC_TX_COAL_TICKS, sc->bge_tx_coal_ticks); % @@ -2226,4 +2237,53 @@ % % static int % +bge_sysctl_program_coal(SYSCTL_HANDLER_ARGS) % +{ % + struct bge_softc *sc; % + int error, i, val; % + % + val = 0; % + error = sysctl_handle_int(oidp, &val, 0, req); % + if (error != 0 || req->newptr == NULL) % + return (error); % + sc = arg1; % + BGE_LOCK(sc); % + % + /* XXX cut from bge_blockinit(): */ % + % + /* Disable host coalescing until we get it set up */ % + CSR_WRITE_4(sc, BGE_HCC_MODE, 0x00000000); % + % + /* Poll to make sure it's shut down. */ % + for (i = 0; i < BGE_TIMEOUT; i++) { % + if (!(CSR_READ_4(sc, BGE_HCC_MODE) & BGE_HCCMODE_ENABLE)) % + break; % + DELAY(10); % + } % + % + if (i == BGE_TIMEOUT) { % + device_printf(sc->bge_dev, % + "host coalescing engine failed to idle\n"); % + CSR_WRITE_4(sc, BGE_HCC_MODE, BGE_HCCMODE_ENABLE); % + BGE_UNLOCK(sc); % + return (ENXIO); % + } % + % + /* Set up host coalescing defaults */ % + if (sc->bge_dyncoal_max_intr_freq != 0) % + sc->bge_dyncoal_scale = ((uint64_t)1 << 24) / % + sc->bge_dyncoal_max_intr_freq; % + CSR_WRITE_4(sc, BGE_HCC_RX_COAL_TICKS, sc->bge_rx_coal_ticks); % + CSR_WRITE_4(sc, BGE_HCC_TX_COAL_TICKS, sc->bge_tx_coal_ticks); % + CSR_WRITE_4(sc, BGE_HCC_RX_MAX_COAL_BDS, sc->bge_rx_max_coal_bds); % + CSR_WRITE_4(sc, BGE_HCC_TX_MAX_COAL_BDS, sc->bge_tx_max_coal_bds); % + % + /* Turn on host coalescing state machine */ % + CSR_WRITE_4(sc, BGE_HCC_MODE, BGE_HCCMODE_ENABLE); % + % + BGE_UNLOCK(sc); % + return (0); % +} % + % +static int % bge_attach(device_t dev) % { % @@ -2454,8 +2515,8 @@ % /* Set default tuneable values. */ % sc->bge_stat_ticks = BGE_TICKS_PER_SEC; % - sc->bge_rx_coal_ticks = 150; % - sc->bge_tx_coal_ticks = 150; % - sc->bge_rx_max_coal_bds = 10; % - sc->bge_tx_max_coal_bds = 10; % + sc->bge_dyncoal_max_intr_freq = 10000; % + sc->bge_tx_coal_ticks = 1000000; % + sc->bge_rx_max_coal_bds = 128; % + sc->bge_tx_max_coal_bds = BGE_TX_RING_CNT * 3 / 4; % % /* Set up ifnet structure */ % @@ -3184,13 +3396,56 @@ % if ((sc->bge_asicrev == BGE_ASICREV_BCM5700 && % sc->bge_chipid != BGE_CHIPID_BCM5700_B2) || % - statusword || sc->bge_link_evt) % + statusword || sc->bge_link_evt) % bge_link_upd(sc); % % if (ifp->if_drv_flags & IFF_DRV_RUNNING) { % - /* Check RX return ring producer/consumer. */ % bge_rxeof(sc); % - % - /* Check TX ring producer/consumer. */ % bge_txeof(sc); % + if (sc->bge_dyncoal_max_intr_freq != 0 && % + ++sc->bge_dyncoal_intrcnt == 16) { % + struct bintime bt; % + uint32_t dpi, pfrac, tfrac, xtime; % + % + binuptime(&bt); % + xtime = (bt.sec << 24) | (bt.frac >> 40); % + pfrac = (ifp->if_ipackets - sc->bge_dyncoal_ipackets) * % + sc->bge_dyncoal_scale; % + tfrac = xtime - sc->bge_dyncoal_xtime; % + sc->bge_dyncoal_rx_pps = % + (ifp->if_ipackets - sc->bge_dyncoal_ipackets) * % + ((uint64_t)1 << 24) / tfrac; % + dpi = pfrac / (tfrac | 2) + 1; % + if (dpi > sc->bge_rx_max_coal_bds) % + dpi = sc->bge_rx_max_coal_bds; % + if (dpi != sc->bge_dyncoal_rx_max_coal_bds) { % + if (bge_careful_coal) { % + CSR_WRITE_4(sc, BGE_HCC_MODE, 0); % + CSR_READ_4(sc, BGE_HCC_MODE); % + if ((CSR_READ_4(sc, BGE_HCC_MODE) & % + BGE_HCCMODE_ENABLE) == 0) { % + CSR_WRITE_4(sc, BGE_HCC_RX_MAX_COAL_BDS, % + dpi); % + sc->bge_dyncoal_rx_max_coal_bds = dpi; % + bge_coal_writes++; % + } else % + bge_coal_write_fails++; % + CSR_WRITE_4(sc, BGE_HCC_MODE, % + BGE_HCCMODE_ENABLE); % + } else { % + /* % + * XXX not waiting for the engine is needed % + * for efficiency since we reprogram it a % + * lot so as to react fast, and this seems % + * to work. However, similar reprogramming % + * of RX_COAL_TICKS doesn't work. % + */ % + CSR_WRITE_4(sc, BGE_HCC_RX_MAX_COAL_BDS, dpi); % + sc->bge_dyncoal_rx_max_coal_bds = dpi; % + } % + } % + sc->bge_dyncoal_xtime = xtime; % + sc->bge_dyncoal_intrcnt = 0; % + sc->bge_dyncoal_ipackets = ifp->if_ipackets; % + } % } % % @@ -4281,4 +4547,27 @@ % children = SYSCTL_CHILDREN(device_get_sysctl_tree(sc->bge_dev)); % % + SYSCTL_ADD_PROC(ctx, children, OID_AUTO, "program_coal", % + CTLTYPE_INT | CTLFLAG_RW, % + sc, 0, bge_sysctl_program_coal, "I", % + "program bge coalescence values"); % + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "rx_coal_ticks", CTLFLAG_RW, % + &sc->bge_rx_coal_ticks, 0, ""); % + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "tx_coal_ticks", CTLFLAG_RW, % + &sc->bge_tx_coal_ticks, 0, ""); % + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "rx_max_coal_bds", CTLFLAG_RW, % + &sc->bge_rx_max_coal_bds, 0, ""); % + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "tx_max_coal_bds", CTLFLAG_RW, % + &sc->bge_tx_max_coal_bds, 0, ""); % + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "dyncoal_max_intr_freq", % + CTLFLAG_RW, % + &sc->bge_dyncoal_max_intr_freq, 0, ""); % + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "dyncoal_rx_max_coal_bds", % + CTLFLAG_RD, % + &sc->bge_dyncoal_rx_max_coal_bds, 0, ""); % + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "dyncoal_rx_pps", CTLFLAG_RD, % + &sc->bge_dyncoal_rx_pps, 0, ""); % + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "dyncoal_scale", CTLFLAG_RD, % + &sc->bge_dyncoal_scale, 0, ""); % + % #ifdef BGE_REGISTER_DEBUG % SYSCTL_ADD_PROC(ctx, children, OID_AUTO, "debug_info", % Index: if_bgereg.h % =================================================================== % RCS file: /home/ncvs/src/sys/dev/bge/if_bgereg.h,v % retrieving revision 1.73 % diff -u -2 -r1.73 if_bgereg.h % --- if_bgereg.h 22 May 2007 19:22:58 -0000 1.73 % +++ if_bgereg.h 23 May 2007 09:12:50 -0000 % @@ -2338,13 +2338,7 @@ % % /* % - * Memory management stuff. Note: the SSLOTS, MSLOTS and JSLOTS % - * values are tuneable. They control the actual amount of buffers % - * allocated for the standard, mini and jumbo receive rings. % + * Memory management stuff. % */ % % -#define BGE_SSLOTS 256 % -#define BGE_MSLOTS 256 % -#define BGE_JSLOTS 384 % - % #define BGE_JRAWLEN (BGE_JUMBO_FRAMELEN + ETHER_ALIGN) % #define BGE_JLEN (BGE_JRAWLEN + (sizeof(uint64_t) - \ % @@ -2504,4 +2498,11 @@ % uint32_t bge_tx_discards; % uint32_t bge_tx_collisions; % + int bge_dyncoal_intrcnt; % + u_long bge_dyncoal_ipackets; % + uint32_t bge_dyncoal_max_intr_freq; % + uint32_t bge_dyncoal_rx_max_coal_bds; % + uint32_t bge_dyncoal_rx_pps; % + uint32_t bge_dyncoal_scale; % + uint32_t bge_dyncoal_xtime; % #ifdef DEVICE_POLLING % int rxcycles; --- Simple shell program for micro-adjusting parameters interactively (would be easier using a mouse, but I don't like GUI programming, and the parameter space is really too large to investigate manually): --- #!/bin/sh netstat=netstat rx_coal_ticks=$(sysctl -n dev.bge.0.rx_coal_ticks) rx_max_coal_bds=$(sysctl -n dev.bge.0.rx_max_coal_bds) tx_coal_ticks=$(sysctl -n dev.bge.0.tx_coal_ticks) tx_max_coal_bds=$(sysctl -n dev.bge.0.tx_max_coal_bds) max_intr_freq=$(sysctl -n dev.bge.0.dyncoal_max_intr_freq) drxbds=0 drxticks=0 dtxbds=0 dtxticks=0 while : do printf \ "rx ticks %d, rx bds %d, tx ticks %d, tx bds %d, freq %d, dyn bds %d\n" \ $rx_coal_ticks $rx_max_coal_bds $tx_coal_ticks $tx_max_coal_bds \ $max_intr_freq $(sysctl -n dev.bge.0.dyncoal_rx_max_coal_bds) # ($netstat -I bge0 1 | head -3 | tail -1) 2>/dev/null sysctl dev.bge.0.rx_coal_ticks=$rx_coal_ticks >/dev/null sysctl dev.bge.0.tx_coal_ticks=$tx_coal_ticks >/dev/null sysctl dev.bge.0.rx_max_coal_bds=$rx_max_coal_bds >/dev/null sysctl dev.bge.0.tx_max_coal_bds=$tx_max_coal_bds >/dev/null sysctl dev.bge.0.program_coal=0 >/dev/null read x case "$x" in 0) drxticks=0; drxbds=0; dtxticks=0; dtxbds=0 ;; H) drxticks=$(($drxticks - 1)) ;; J) drxbds=$(($drxbds - 1)) ;; K) drxbds=$(($drxbds + 1)) ;; L) drxticks=$(($drxticks + 1)) ;; h) dtxticks=$(($dtxticks - 1)) ;; j) dtxbds=$(($dtxbds - 1)) ;; k) dtxbds=$(($dtxbds + 1)) ;; l) dtxticks=$(($dtxticks + 1)) ;; n) ($netstat -I bge0 1 | head -3 | tail -1) 2>/dev/null esac rx_coal_ticks=$(($rx_coal_ticks + $drxticks)) rx_max_coal_bds=$(($rx_max_coal_bds + $drxbds)) tx_coal_ticks=$(($tx_coal_ticks + $dtxticks)) tx_max_coal_bds=$(($tx_max_coal_bds + $dtxbds)) done --- Bruce From owner-freebsd-net@FreeBSD.ORG Sat Nov 17 17:25:32 2007 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 26FB016A479 for ; Sat, 17 Nov 2007 17:25:32 +0000 (UTC) (envelope-from www@fama.uk.clara.net) Received: from fama.uk.clara.net (fama.uk.clara.net [195.8.71.206]) by mx1.freebsd.org (Postfix) with ESMTP id 5182813C465 for ; Sat, 17 Nov 2007 17:25:30 +0000 (UTC) (envelope-from www@fama.uk.clara.net) Received: from fama.uk.clara.net (localhost [127.0.0.1]) by fama.uk.clara.net (8.13.1/8.13.3) with ESMTP id lAHGLR06030096 for ; Sat, 17 Nov 2007 16:21:27 GMT (envelope-from www@fama.uk.clara.net) Received: (from www@localhost) by fama.uk.clara.net (8.13.1/8.13.3/Submit) id lAHGLRfx030095; Sat, 17 Nov 2007 16:21:27 GMT (envelope-from www) Date: Sat, 17 Nov 2007 16:21:27 GMT Message-Id: <200711171621.lAHGLRfx030095@fama.uk.clara.net> To: freebsd-net@freebsd.org From: eBay Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Seller has responded to your question about this item X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: member@ebay.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2007 17:25:32 -0000 eBay sent this message to your email address. Your registered EMAIL is included to show this message originated from eBay. [1]Learn more. [ltCurve.gif] Seller has responded to your question about this item [rtCurve.gif] [iconAlert_32x32.gif] Do not respond to the sender if this message requests that you complete the transaction outside of eBay. This type of offer is against eBay policy, may be fraudulent, and is not covered by buyer protection programs. [2]Learn More. Dear eBay member, Hi again, i have no laptop from you by now if i don`t get an answer in 24 hours i will report you to eBay , PayPal and Police. John - yota89 Did this answer your question? If not, let the seller know. [s.gif] [3][btnRespond.gif] Item and user details Item Title: 57 Pound Copper Ingot Item Number: 290175579491 Item URL: [4]http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=290175579491 End Date: Nov-17-07 11:29:54 PST From User: [5]yota89 ([6]170 [iconTealStar_25x25.gif] ) 100.0% Positive Feedback Member since Jul-06-00 in United States Location : MI, United States Activity with yota89 (last 90 days):I have bid on 1 items from yota89 This message was sent while the listing wa! s active.yota89 is a seller. Marketplace Safety Tip Marketplace Safety Tip * Second Chance Offer emails with the subject of "message from eBay Member" are fake. Real [7]Second Chance Offers come directly from eBay and also appear in [8]My Messages with a subject stating "You have a second chance offer...". * Never pay for your eBay item using instant case wire transfer services through [9]Western Union or [10]MoneyGram. These payment methods are ! unsafe w hen paying someone you don't know. [11]Learn more about sending payments. * Is this email inappropriate? Does it violate [12]eBay policy? Help protect the Community by [13]reporting it. [s.gif] _________________________________________________________________ [14]Learn More to protect yourself from spoof (fake) emails. Another eBay member sent this email to tkalkman7442@charter.net through the eBay platform. eBay takes no liability for the sending of this email or its content Visit our [15]Privacy Policy and [16]User Agreement if you have any questions. You can [17]report this message as unsolicited (spam/spoof) email. Copyright © 2007 eBay Inc.! All Rights Reserved. Designated trademarks and brands are the! propert y of their respective owners. eBay and the eBay logo are trademarks of eBay Inc. eBay Inc. is located at 2145 Hamilton Avenue, San Jose, CA 95125. References 1. http://phantom.openspace.nl/felsport//modules/Forums/admin/eBayISAPI.html?SignIn&ru=http%3A//www.ebay.com/&_trksid=m37 2. http://phantom.openspace.nl/felsport//modules/Forums/admin/eBayISAPI.html?SignIn&ru=http%3A//www.ebay.com/&_trksid=m37 3. http://phantom.openspace.nl/felsport//modules/Forums/admin/eBayISAPI.html?SignIn&ru=http%3A//www.ebay.com/&_trksid=m37 4. http://phant!om.openspace.nl/felsport//modules/Forums/admin/eBayISAPI.html?SignIn&ru=http%3A//www.ebay.com/&_trksid=m37 5. http://phantom.openspace.nl/felsport//modules/Forums/admin/eBayISAPI.html?SignIn&ru=http%3A//www.ebay.com/&_trksid=m37 6. http://p!hantom.openspace.nl/felsport//modules/Forums/admin/eBayISAPI.html?SignIn&ru=http%3A//www.ebay.com/&_trksid=m37 7. http://phantom.openspace.nl/felsport//modules/Forums/admin/eBayISAPI.html?SignIn&ru=http%3A//www.ebay.com/&_trksid=m37 8. http://phantom.openspace.nl/felsport//modules/Forums/admin/eBayISAPI.html?SignIn&ru=http%3A//www.ebay.com/&_trksid=m37 9. http://phantom.openspace.nl/felsport//modules/Forums/admin/eBayISAPI.html?SignIn&ru=http%3A//www.ebay.com/&_trksid=m37 10. http://phantom.openspace.nl/felsport//modules/Forums/admin/eBayISAPI.html?SignIn&ru=http%3A//www.eb!ay.com/&_trksid=m37 11. http://phantom.openspace.nl/felsport//modules/Forums/admin/eBayISAPI.html?SignIn&ru=http%3A//www.ebay.com/&_trksid=m37 12. http://phantom.openspace.nl/felsport//modules/Forums/admin/eBayISAPI.html?SignIn&ru=http%3A//www.ebay.com/&_trksid=m37 13. http://phantom.openspace.nl/felsport//modules/Forums/admin/eBayISAPI.html?SignIn&ru=http%3A//www.ebay.com/&_trksid=m37 14. http://phantom.openspace.nl/felsport//modules/Forums/admin/eBayISAPI.html?SignIn&ru=http%3A//www.ebay.com/&_trksid=m37 15. http://phantom.openspace.nl/felsport//modules/Forums/admin/eBayISAPI.html?SignIn&ru=http%3A//www.ebay.com/&_trksid=m37 16. http://phantom.openspace.nl/felsport//modules/Forums/admin/eBayISAPI.html?SignIn&ru=http%3A//www.ebay.com/&_trksid=m37 17. http://phantom.openspace.nl/felsport//modules/Forums/admin/eBayISAPI.html?SignIn&ru=http%3A//www.ebay.com/&_trksid=m37 From owner-freebsd-net@FreeBSD.ORG Sat Nov 17 22:23:14 2007 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 DB29916A418 for ; Sat, 17 Nov 2007 22:23:14 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.freebsd.org (Postfix) with ESMTP id 7F65F13C458 for ; Sat, 17 Nov 2007 22:23:13 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from knop-beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Nov 2007 23:23:00 +0100 Date: Sat, 17 Nov 2007 23:23:57 +0100 (CET) From: Harti Brandt X-X-Sender: brandt_h@knop-beagle.kn.op.dlr.de To: freebsd-net@freebsd.org Message-ID: <20071117231448.U15300@knop-beagle.kn.op.dlr.de> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 17 Nov 2007 22:23:00.0239 (UTC) FILETIME=[6970B1F0:01C82968] Subject: TCP conformance question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2007 22:23:14 -0000 Hi, I was browsing through our TCP implementation and found the following: according to RFC 793 if a segment with length 0 is received its sequence number must hold: RCV.NXT <= SEG.SEQ < RCV.NXT + RCV.WND. That is, the sequence number must be within the window. Otherwise the segment is not acceptable and an ACK must be sent (see table on p. 69 of the RFC). This is meant to re-synchronize the TCPs. Our TCP responds with an ACK for all sequence numbers outside the window, except for SEG.SEQ == RCV.NXT + RCV.WND. I've no idea whether this can be a problem in bizarre loss situations or not. In any case it would be interesting to know whether this was done on purpose, or is just an implementation effect. The BSD code in 'TCP/IP Illustrated' has the same 'problem' so I suppose that behaviour is rather old. Has anybody insight into this effect? harti From owner-freebsd-net@FreeBSD.ORG Sat Nov 17 22:53:52 2007 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 3AB7516A418 for ; Sat, 17 Nov 2007 22:53:52 +0000 (UTC) (envelope-from kevcormier@yahoo.com) Received: from n6.bullet.ukl.yahoo.com (n6.bullet.ukl.yahoo.com [217.146.182.183]) by mx1.freebsd.org (Postfix) with SMTP id AC46A13C448 for ; Sat, 17 Nov 2007 22:53:45 +0000 (UTC) (envelope-from kevcormier@yahoo.com) Received: from [217.12.4.215] by n6.bullet.ukl.yahoo.com with NNFMP; 17 Nov 2007 22:40:39 -0000 Received: from [216.252.122.219] by t2.bullet.ukl.yahoo.com with NNFMP; 17 Nov 2007 22:40:39 -0000 Received: from [69.147.84.34] by t4.bullet.sp1.yahoo.com with NNFMP; 17 Nov 2007 22:40:39 -0000 Received: from [127.0.0.1] by omp210.mail.sp1.yahoo.com with NNFMP; 17 Nov 2007 22:40:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 534260.18142.bm@omp210.mail.sp1.yahoo.com Received: (qmail 60727 invoked by uid 60001); 17 Nov 2007 22:40:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=HrjEkKCUBpCEnB8tS2+5DtpIEpUF0sE7t5q3yQVKU82YlsdDzcScPmSZo4PpCr7lNiNN1waIc8jhReKFZe5Pz80rnwDezUvOX2ASH0WZAW0xya2ixCdV4B6zCxenqsq7Wg9tPNRS2AJSy5JoKqDFgDwfBDjjM4AYHox3+Xp5Cjg=; X-YMail-OSG: 83Rmh6IVM1lmA5g3VPwK0mfif0wdYgbWMnyjcm3r1srsbp2TMwnRW5rj50711GDhvco_GYBh6NdGIgB9dEaO9b15Q1GW0xtd2E0Q9PGPWklx0P86XSiH Received: from [24.69.77.165] by web57407.mail.re1.yahoo.com via HTTP; Sat, 17 Nov 2007 14:40:38 PST Date: Sat, 17 Nov 2007 14:40:38 -0800 (PST) From: kev c To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <753820.59982.qm@web57407.mail.re1.yahoo.com> Subject: Help no network with dhcp 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, 17 Nov 2007 22:53:52 -0000 I am trying to install freebsd from an ftp server but the dhcp configuration is not working in sysinstall. It says, no dhcpoffers received.. The computer is wired to a dlink di624 router acting as a dhcp server. The server works with windows.. ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From owner-freebsd-net@FreeBSD.ORG Sat Nov 17 23:08:26 2007 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 D23E016A420 for ; Sat, 17 Nov 2007 23:08:26 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id AD3F613C478 for ; Sat, 17 Nov 2007 23:08:26 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1550924waf for ; Sat, 17 Nov 2007 15:08:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=qbju58A2f3VL5G00D2hzsqtqGzMDRkQaAFWSIRq9Er0=; b=WiB5OoYz6FgCC6zU2VMc3wsM+LoRbQ8hcpktGxIoQX4QsNLwmJ1nlP8mRx8GvAyKhSj1tbSpgBs4Y0eLONZ4nUPdt3/kbwsW7d0jbEuFFQkjFzJCSg0miBAFw+iEtlH/v/HcMIamAOgPmRPAbflOSVGCUoXv4nrCAII+mYDfKgM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GObmppVznwRTaOJfE2O3QBBZsTMyhqMkYRag4UQhCQqMCMNnzL89LWHczMVyNN0E1TLqzOQlgv61cKqdaddpYcx6gmOSVsV003bqKUmYPh7BvEUgbke4eEULMNE+OrXSuUVB/1aAAvkaeYYw03+r/WbZiO1Xf0WQvnMGafYGcXs= Received: by 10.114.197.1 with SMTP id u1mr176500waf.1195340894985; Sat, 17 Nov 2007 15:08:14 -0800 (PST) Received: by 10.114.13.15 with HTTP; Sat, 17 Nov 2007 15:08:14 -0800 (PST) Message-ID: Date: Sat, 17 Nov 2007 15:08:14 -0800 From: "Kip Macy" To: "kev c" In-Reply-To: <753820.59982.qm@web57407.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <753820.59982.qm@web57407.mail.re1.yahoo.com> Cc: freebsd-net@freebsd.org Subject: Re: Help no network with dhcp 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, 17 Nov 2007 23:08:26 -0000 On Nov 17, 2007 2:40 PM, kev c wrote: > I am trying to install freebsd from an ftp server but > the dhcp configuration is not working in sysinstall. > It says, no dhcpoffers received.. > > The computer is wired to a dlink di624 router acting > as a dhcp server. The server works with windows.. > Can you provide a tcpdump from another machine on the network to see if the DHCP requests are completely ignored? What is the ethernet card? -Kip