From owner-freebsd-net Sun Jun 30 10:19:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B8DE37B400 for ; Sun, 30 Jun 2002 10:19:13 -0700 (PDT) Received: from forrie.ne.client2.attbi.com (forrie.ne.client2.attbi.com [24.147.156.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CC6443E13 for ; Sun, 30 Jun 2002 10:19:12 -0700 (PDT) (envelope-from forrie@forrie.com) Received: from boom.forrie.com (internal-22.forrie.net. [192.168.1.22]) by forrie.ne.client2.attbi.com with id g5UHJA805174 for ; Sun, 30 Jun 2002 13:19:10 -0400 (EDT) Message-Id: <5.1.0.14.2.20020630131553.01c13ce0@192.168.1.1> X-Sender: forrie@192.168.1.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 30 Jun 2002 13:17:08 -0400 To: freebsd-net@freebsd.org From: Forrest Aldrich Subject: Redundant network connections & Load Balancing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RAVMilter-Version: 8.3.0(snapshot 20010925) (forrie.ne.client2.attbi.com) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In a Sysadmin (Jan 2002) article, there is explained how to use Linux as a "router" using redundant network connections (DSL + dialup), as well as load balancing between the two. I recall this required some special kernel configuration directives: CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y and the "iproute" toolset, which must be installed separately; and a few other changes. I wonder if the same (if not more advanced) could be accomplished with FreeBSD. Take for example, Company A who wants to provision a few sDSL lines. Creating a FreeBSD gateway/router and load balancing the traffic amoungst that (with some careful ipf or ipfirewall rulesets) could be very effective, and a lot cheaper than provisioning a single pipe in some cases. One could take multiple connections like dialup, dsl and cable modem and make the most out of that as well. I wonder if anyone has accomplished this with FreeBSD-4.x or 5.x; and if they could share that info. Thanks, Forrest To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 30 10:21: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BD2A37B400 for ; Sun, 30 Jun 2002 10:21:04 -0700 (PDT) Received: from mail7.wi.rr.com (mkc-24-94-162-160.kc.rr.com [24.94.162.160]) by mx1.FreeBSD.org (Postfix) with ESMTP id D702E43E13 for ; Sun, 30 Jun 2002 10:21:03 -0700 (PDT) (envelope-from srgtd@wi.rr.com) Received: from JIMMY ([24.160.242.2]) by mail7.wi.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Sun, 30 Jun 2002 12:17:43 -0500 Date: Sun, 30 Jun 2002 12:15:58 -0500 From: srgtd X-Mailer: The Bat! (v1.49) UNREG / CD5BF9353B3B7091 Reply-To: srgtd Organization: SOD X-Priority: 3 (Normal) Message-ID: <0311990032.20020630121558@wi.rr.com> To: Anthony Volodkin Cc: freebsd-net@FreeBSD.ORG Subject: Re: problems with mpd as a pptp server Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org hi there, Do you see the service 'listening' using the following command: # netstat -a Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 myIPADDR.pptp *.* LISTEN >mpd uses netgraph to do all it's protocoll work. >the sockets therefore cannot be assigned to a process and >don't show up in sockstat. i see the PPTP service when i do: # sockstat -4 USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS user mpd 1984 14 tcp4 publicIPADDR:1723 *:* im using 4.4-release with mpd-3.8. hope this helps. Also...does anyone know why Windows 98 doesn't work with MPD? I haven't heard 1 successful story with FBSD -> Win98 (i can get FBSD -> Win2K to work with no problems using CHAP and PAP). Any insight would be great. JE> On Sun, 30 Jun 2002, Anthony Volodkin wrote: >> Hi, >> >> Julian Elischer suggested that I use mpd to setup a pptp link instead of >> PoPtoP (thank you) >> I am now having problems with mpd. I configured it as a pptp server >> accoring to instructions, but it never responds to requests. >> Furthermore, I doubt it even listens for them, because it does not >> appear in the output of 'sockstat' as bound to a socket (like apache, >> and others do). How can I get it to bind to a port and listen? I did >> specify my external ip in the mpd.links file. On an unrelated note, if i >> start mpd and run 'show link', i get the following: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 30 16:47:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C55E37B400 for ; Sun, 30 Jun 2002 16:47:42 -0700 (PDT) Received: from creme-brulee.marcuscom.com (rdu57-17-158.nc.rr.com [66.57.17.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87B3C43E13 for ; Sun, 30 Jun 2002 16:47:41 -0700 (PDT) (envelope-from marcus@FreeBSD.org) Received: from shumai.marcuscom.com (marcus@shumai.marcuscom.com [192.168.1.4]) by creme-brulee.marcuscom.com (8.12.4/8.12.3) with ESMTP id g5UNkZBB043052 for ; Sun, 30 Jun 2002 19:46:35 -0400 (EDT) (envelope-from marcus@FreeBSD.org) Subject: Skinny (SCCP) protocol gateway for libalias From: Joe Marcus Clarke To: freebsd-net@FreeBSD.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-BM0g/K5RtkZJIMcORZK+" X-Mailer: Ximian Evolution 1.0.7 Date: 30 Jun 2002 19:47:37 -0400 Message-Id: <1025480857.48597.33.camel@shumai.marcuscom.com> Mime-Version: 1.0 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --=-BM0g/K5RtkZJIMcORZK+ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I've written a Skinny (the call setup protocol used by Cisco IP phones) NAT ALG for libalias. I sent the code to ru for review, but he's too busy. He wondered how any others would find it useful.=20 Basically, it allows Cisco IP phones behind a FreeBSD running natd or ppp to communicate correctly with a public Cisco Call Manager. It is based on sniffer decodes from ethereal, and has been working for me for some time. If there isn't a big demand for this, I guess there's not a reason to commit it to the tree. However, if people find this useful, it might make a nice addition. Joe --=-BM0g/K5RtkZJIMcORZK+ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQA9H5iZb2iPiv4Uz4cRAs3YAJ9GdIRZUnH7XzjftLhMhqAqspjtsgCgiMmM aaBsPYOfBpqYYSV9zJ0glaU= =6y9D -----END PGP SIGNATURE----- --=-BM0g/K5RtkZJIMcORZK+-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 30 17:11:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D422137B401 for ; Sun, 30 Jun 2002 17:11:45 -0700 (PDT) Received: from web20903.mail.yahoo.com (web20903.mail.yahoo.com [216.136.226.225]) by mx1.FreeBSD.org (Postfix) with SMTP id 3500043E1D for ; Sun, 30 Jun 2002 17:11:45 -0700 (PDT) (envelope-from bsddiy@yahoo.com) Message-ID: <20020701001144.10685.qmail@web20903.mail.yahoo.com> Received: from [218.108.152.96] by web20903.mail.yahoo.com via HTTP; Sun, 30 Jun 2002 17:11:44 PDT Date: Sun, 30 Jun 2002 17:11:44 -0700 (PDT) From: David Xu Subject: ppp begin core dump To: freebsd-current@freebsd.org, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org cvsup from yesterday, ppp began core dump on my machine. back trace: GNU gdb 5.2.0 (FreeBSD) 20020627 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-undermydesk-freebsd"...(no debugging symbols found)... Core was generated by `ppp'. Program terminated with signal 10, Bus error. Reading symbols from /usr/lib/libcrypt.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libcrypt.so.2 Reading symbols from /usr/lib/libmd.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libmd.so.2 Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libutil.so.3 Reading symbols from /usr/lib/libz.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libz.so.2 Reading symbols from /usr/lib/libalias.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libalias.so.4 Reading symbols from /usr/lib/libcrypto.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libcrypto.so.2 Reading symbols from /usr/lib/libradius.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libradius.so.1 Reading symbols from /usr/lib/libnetgraph.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libnetgraph.so.1 Reading symbols from /usr/lib/libc.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libc.so.5 Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/libexec/ld-elf.so.1 #0 0x280f886f in PunchFWHole () from /usr/lib/libalias.so.4 (gdb) bt #0 0x280f886f in PunchFWHole () from /usr/lib/libalias.so.4 #1 0x280f694a in FindNewPortGroup () from /usr/lib/libalias.so.4 #2 0x280f68f2 in FindNewPortGroup () from /usr/lib/libalias.so.4 #3 0x280f7e89 in HouseKeeping () from /usr/lib/libalias.so.4 #4 0x280f2815 in PacketAliasOut () from /usr/lib/libalias.so.4 #5 0x0807cfa5 in NgRecvData () #6 0x0806b0c2 in NgRecvData () #7 0x08067705 in NgRecvData () #8 0x08070968 in NgRecvData () #9 0x080708bf in NgRecvData () #10 0x0804d1a5 in NgRecvData () #11 0x0806d7e7 in NgRecvData () #12 0x0806d700 in NgRecvData () #13 0x0804b5c9 in NgRecvData () (gdb) quit -David Xu __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 30 17:44:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44D7737B400; Sun, 30 Jun 2002 17:44:54 -0700 (PDT) Received: from tp.databus.com (p72-186.acedsl.com [66.114.72.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 746CD43E09; Sun, 30 Jun 2002 17:44:53 -0700 (PDT) (envelope-from barney@databus.com) Received: from databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.4/8.12.3) with ESMTP id g610iqQZ056833; Sun, 30 Jun 2002 20:44:52 -0400 (EDT) (envelope-from barney@databus.com) Received: (from barney@localhost) by databus.com (8.12.4/8.12.4/Submit) id g610iqJY056832; Sun, 30 Jun 2002 20:44:52 -0400 (EDT) Date: Sun, 30 Jun 2002 20:44:52 -0400 From: Barney Wolff To: Joe Marcus Clarke Cc: freebsd-net@FreeBSD.ORG Subject: Re: Skinny (SCCP) protocol gateway for libalias Message-ID: <20020630204452.A56736@tp.databus.com> References: <1025480857.48597.33.camel@shumai.marcuscom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1025480857.48597.33.camel@shumai.marcuscom.com>; from marcus@FreeBSD.ORG on Sun, Jun 30, 2002 at 07:47:37PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'd be happy to see this as a port, less happy as base code. On Sun, Jun 30, 2002 at 07:47:37PM -0400, Joe Marcus Clarke wrote: > I've written a Skinny (the call setup protocol used by Cisco IP phones) > NAT ALG for libalias. I sent the code to ru for review, but he's too > busy. He wondered how any others would find it useful. > > Basically, it allows Cisco IP phones behind a FreeBSD running natd or > ppp to communicate correctly with a public Cisco Call Manager. It is > based on sniffer decodes from ethereal, and has been working for me for > some time. > > If there isn't a big demand for this, I guess there's not a reason to > commit it to the tree. However, if people find this useful, it might > make a nice addition. -- Barney Wolff I never met a computer I didn't like. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 30 18: 8:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B1FF37B409 for ; Sun, 30 Jun 2002 18:08:50 -0700 (PDT) Received: from creme-brulee.marcuscom.com (rdu57-17-158.nc.rr.com [66.57.17.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DEC643E09 for ; Sun, 30 Jun 2002 18:08:49 -0700 (PDT) (envelope-from marcus@FreeBSD.org) Received: from shumai.marcuscom.com (marcus@shumai.marcuscom.com [192.168.1.4]) by creme-brulee.marcuscom.com (8.12.4/8.12.3) with ESMTP id g6117lBB043405; Sun, 30 Jun 2002 21:07:47 -0400 (EDT) (envelope-from marcus@FreeBSD.org) Subject: Re: Skinny (SCCP) protocol gateway for libalias From: Joe Marcus Clarke To: Barney Wolff Cc: freebsd-net@FreeBSD.org In-Reply-To: <20020630204452.A56736@tp.databus.com> References: <1025480857.48597.33.camel@shumai.marcuscom.com> <20020630204452.A56736@tp.databus.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-OZB4HcFO5YTfkN7YjkbJ" X-Mailer: Ximian Evolution 1.0.7 Date: 30 Jun 2002 21:08:50 -0400 Message-Id: <1025485730.48597.35.camel@shumai.marcuscom.com> Mime-Version: 1.0 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --=-OZB4HcFO5YTfkN7YjkbJ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2002-06-30 at 20:44, Barney Wolff wrote: > I'd be happy to see this as a port, less happy as base code. Why less happy as base code? Like all other libalias ALGs, this wouldn't be very intrusive to the OS. It simply adds one new file to the source tree. Joe >=20 > On Sun, Jun 30, 2002 at 07:47:37PM -0400, Joe Marcus Clarke wrote: > > I've written a Skinny (the call setup protocol used by Cisco IP phones) > > NAT ALG for libalias. I sent the code to ru for review, but he's too > > busy. He wondered how any others would find it useful.=20 > >=20 > > Basically, it allows Cisco IP phones behind a FreeBSD running natd or > > ppp to communicate correctly with a public Cisco Call Manager. It is > > based on sniffer decodes from ethereal, and has been working for me for > > some time. > >=20 > > If there isn't a big demand for this, I guess there's not a reason to > > commit it to the tree. However, if people find this useful, it might > > make a nice addition. >=20 > --=20 > Barney Wolff > I never met a computer I didn't like. >=20 --=-OZB4HcFO5YTfkN7YjkbJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQA9H6uib2iPiv4Uz4cRAiIFAKCjNp8y+wpn2+L3k+FJzEX2C8oDjgCgr7VL u9G92hOXan5CGC2n6zgxvMo= =x4UR -----END PGP SIGNATURE----- --=-OZB4HcFO5YTfkN7YjkbJ-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 30 18:37:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3775737B400; Sun, 30 Jun 2002 18:37:22 -0700 (PDT) Received: from tp.databus.com (p72-186.acedsl.com [66.114.72.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F1C743E0A; Sun, 30 Jun 2002 18:37:21 -0700 (PDT) (envelope-from barney@databus.com) Received: from databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.4/8.12.3) with ESMTP id g611b4QZ057282; Sun, 30 Jun 2002 21:37:04 -0400 (EDT) (envelope-from barney@databus.com) Received: (from barney@localhost) by databus.com (8.12.4/8.12.4/Submit) id g611b4MZ057281; Sun, 30 Jun 2002 21:37:04 -0400 (EDT) Date: Sun, 30 Jun 2002 21:37:04 -0400 From: Barney Wolff To: Joe Marcus Clarke Cc: Barney Wolff , freebsd-net@FreeBSD.org Subject: Re: Skinny (SCCP) protocol gateway for libalias Message-ID: <20020630213704.A57193@tp.databus.com> References: <1025480857.48597.33.camel@shumai.marcuscom.com> <20020630204452.A56736@tp.databus.com> <1025485730.48597.35.camel@shumai.marcuscom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1025485730.48597.35.camel@shumai.marcuscom.com>; from marcus@FreeBSD.org on Sun, Jun 30, 2002 at 09:08:50PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I knew I should have explained. :) What I fear is volatility, with an undocumented proprietary protocol. And suppose Cisco abandons it for something completely different - when would it be aged out? My instinct is to wish for more modularity, although I have to say that libalias is not all that big today. None of this carries much weight. On Sun, Jun 30, 2002 at 09:08:50PM -0400, Joe Marcus Clarke wrote: > On Sun, 2002-06-30 at 20:44, Barney Wolff wrote: > > I'd be happy to see this as a port, less happy as base code. > > Why less happy as base code? Like all other libalias ALGs, this > wouldn't be very intrusive to the OS. It simply adds one new file to > the source tree. > > Joe > > > > > On Sun, Jun 30, 2002 at 07:47:37PM -0400, Joe Marcus Clarke wrote: > > > I've written a Skinny (the call setup protocol used by Cisco IP phones) > > > NAT ALG for libalias. I sent the code to ru for review, but he's too > > > busy. He wondered how any others would find it useful. > > > > > > Basically, it allows Cisco IP phones behind a FreeBSD running natd or > > > ppp to communicate correctly with a public Cisco Call Manager. It is > > > based on sniffer decodes from ethereal, and has been working for me for > > > some time. > > > > > > If there isn't a big demand for this, I guess there's not a reason to > > > commit it to the tree. However, if people find this useful, it might > > > make a nice addition. > > > > -- > > Barney Wolff > > I never met a computer I didn't like. > > > -- Barney Wolff I never met a computer I didn't like. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 30 18:41:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A53DC37B400 for ; Sun, 30 Jun 2002 18:41:35 -0700 (PDT) Received: from creme-brulee.marcuscom.com (rdu57-17-158.nc.rr.com [66.57.17.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7E5043E1D for ; Sun, 30 Jun 2002 18:41:34 -0700 (PDT) (envelope-from marcus@FreeBSD.org) Received: from shumai.marcuscom.com (marcus@shumai.marcuscom.com [192.168.1.4]) by creme-brulee.marcuscom.com (8.12.4/8.12.3) with ESMTP id g611eXBB081666; Sun, 30 Jun 2002 21:40:33 -0400 (EDT) (envelope-from marcus@FreeBSD.org) Subject: Re: Skinny (SCCP) protocol gateway for libalias From: Joe Marcus Clarke To: Barney Wolff Cc: freebsd-net@FreeBSD.org In-Reply-To: <20020630213704.A57193@tp.databus.com> References: <1025480857.48597.33.camel@shumai.marcuscom.com> <20020630204452.A56736@tp.databus.com> <1025485730.48597.35.camel@shumai.marcuscom.com> <20020630213704.A57193@tp.databus.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-cnul0qaoX2OONnCuYsae" X-Mailer: Ximian Evolution 1.0.7 Date: 30 Jun 2002 21:41:36 -0400 Message-Id: <1025487696.48597.43.camel@shumai.marcuscom.com> Mime-Version: 1.0 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --=-cnul0qaoX2OONnCuYsae Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2002-06-30 at 21:37, Barney Wolff wrote: > I knew I should have explained. :) >=20 > What I fear is volatility, with an undocumented proprietary protocol. > And suppose Cisco abandons it for something completely different - > when would it be aged out? You bring up a good point. Volatility is something I didn't consider.=20 Thanks. Joe >=20 > My instinct is to wish for more modularity, although I have to say > that libalias is not all that big today. >=20 > None of this carries much weight. >=20 > On Sun, Jun 30, 2002 at 09:08:50PM -0400, Joe Marcus Clarke wrote: > > On Sun, 2002-06-30 at 20:44, Barney Wolff wrote: > > > I'd be happy to see this as a port, less happy as base code. > >=20 > > Why less happy as base code? Like all other libalias ALGs, this > > wouldn't be very intrusive to the OS. It simply adds one new file to > > the source tree. > >=20 > > Joe > >=20 > > >=20 > > > On Sun, Jun 30, 2002 at 07:47:37PM -0400, Joe Marcus Clarke wrote: > > > > I've written a Skinny (the call setup protocol used by Cisco IP pho= nes) > > > > NAT ALG for libalias. I sent the code to ru for review, but he's t= oo > > > > busy. He wondered how any others would find it useful.=20 > > > >=20 > > > > Basically, it allows Cisco IP phones behind a FreeBSD running natd = or > > > > ppp to communicate correctly with a public Cisco Call Manager. It = is > > > > based on sniffer decodes from ethereal, and has been working for me= for > > > > some time. > > > >=20 > > > > If there isn't a big demand for this, I guess there's not a reason = to > > > > commit it to the tree. However, if people find this useful, it mig= ht > > > > make a nice addition. > > >=20 > > > --=20 > > > Barney Wolff > > > I never met a computer I didn't like. > > >=20 > >=20 >=20 >=20 >=20 > --=20 > Barney Wolff > I never met a computer I didn't like. >=20 --=-cnul0qaoX2OONnCuYsae Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQA9H7NQb2iPiv4Uz4cRAigbAJ0W1ZdzpwqB2NVEfS9RPXrT66pqbwCdFtuN 97Gukd7hKi5goUG3PRo2boM= =cN8Q -----END PGP SIGNATURE----- --=-cnul0qaoX2OONnCuYsae-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 30 20:29: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C578437B400; Sun, 30 Jun 2002 20:29:00 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48A2C43E0A; Sun, 30 Jun 2002 20:29:00 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.3/8.12.3) with ESMTP id g613Swri014390; Sun, 30 Jun 2002 20:28:58 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id g613Sw0D014389; Sun, 30 Jun 2002 20:28:58 -0700 Date: Sun, 30 Jun 2002 20:28:58 -0700 From: Brooks Davis To: Joe Marcus Clarke Cc: Barney Wolff , freebsd-net@FreeBSD.ORG Subject: Re: Skinny (SCCP) protocol gateway for libalias Message-ID: <20020630202858.B10041@Odin.AC.HMC.Edu> References: <1025480857.48597.33.camel@shumai.marcuscom.com> <20020630204452.A56736@tp.databus.com> <1025485730.48597.35.camel@shumai.marcuscom.com> <20020630213704.A57193@tp.databus.com> <1025487696.48597.43.camel@shumai.marcuscom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1025487696.48597.43.camel@shumai.marcuscom.com>; from marcus@FreeBSD.ORG on Sun, Jun 30, 2002 at 09:41:36PM -0400 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Jun 30, 2002 at 09:41:36PM -0400, Joe Marcus Clarke wrote: > On Sun, 2002-06-30 at 21:37, Barney Wolff wrote: > > I knew I should have explained. :) > > > > What I fear is volatility, with an undocumented proprietary protocol. > > And suppose Cisco abandons it for something completely different - > > when would it be aged out? > > You bring up a good point. Volatility is something I didn't consider. > Thanks. IMO you shouldn't consider it. Cisco will probably support this protocol for years. Even if they "abandon" it, it will still be supported because there are already sites with thousands of phone that aren't going to upgrade on a whim. I believe it should go in. If at some point in the future it is actually gone from real use, then it can be removed. -- Brooks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 30 21:10:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFDED37B400 for ; Sun, 30 Jun 2002 21:10:55 -0700 (PDT) Received: from brainlink.com (mail.brainlink.com [66.228.0.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0867C43E09 for ; Sun, 30 Jun 2002 21:10:55 -0700 (PDT) (envelope-from anthonyv@brainlink.com) Received: from [24.189.7.159] (account anthonyv HELO brainlink.com) by brainlink.com (CommuniGate Pro SMTP 3.5.3) with ESMTP id 14352926 for freebsd-net@freebsd.org; Mon, 01 Jul 2002 00:00:16 -0400 Message-ID: <3D1FD641.4050903@brainlink.com> Date: Mon, 01 Jul 2002 00:10:41 -0400 From: Anthony Volodkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a) Gecko/20020612 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: problems with mpd as a pptp server References: <0311990032.20020630121558@wi.rr.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, A few notes: - Thanks again, Julian! I tried your configuration and now mpd binds to a port!!! You are awesome. Apparently my mistake was that I had only one entry in the mpd.links file. This should be mentioned in the docs, I didn't see it there. Oh yea, and its mpd 3.8, of course :), that silly typo. - Now that perfectly works, (proxy-arp too, is very impressive) I am trying to figure out how to forward broadcast packets from ng0 to fxp0 and vice-versa. Something tells me since this is an interface created by netgraph, it should be possible. I tried the ether.bridge in /usr/share/examples/netgraph/ but I got the same error as I did with tun0: interface ng0 not found. I suppose this is reasonable and intended. - srgtd: I haven't tried mpd with 98 yet, but I did try with an XP client. That works fine. If i end up setting that up, I will let you know. - Thanks everyone! Anthony Volodkin srgtd wrote: >hi there, > >Do you see the service 'listening' using the following command: > ># netstat -a >Active Internet connections (including servers) >Proto Recv-Q Send-Q Local Address Foreign Address (state) >tcp4 0 0 myIPADDR.pptp *.* LISTEN > > > >>mpd uses netgraph to do all it's protocoll work. >>the sockets therefore cannot be assigned to a process and >>don't show up in sockstat. >> >> > >i see the PPTP service when i do: > ># sockstat -4 >USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS >user mpd 1984 14 tcp4 publicIPADDR:1723 *:* > >im using 4.4-release with mpd-3.8. > >hope this helps. > >Also...does anyone know why Windows 98 doesn't work with MPD? I >haven't heard 1 successful story with FBSD -> Win98 (i can get FBSD -> >Win2K to work with no problems using CHAP and PAP). Any insight would >be great. > >JE> On Sun, 30 Jun 2002, Anthony Volodkin wrote: > > >>>Hi, >>> >>>Julian Elischer suggested that I use mpd to setup a pptp link instead of >>>PoPtoP (thank you) >>>I am now having problems with mpd. I configured it as a pptp server >>>accoring to instructions, but it never responds to requests. >>> Furthermore, I doubt it even listens for them, because it does not >>>appear in the output of 'sockstat' as bound to a socket (like apache, >>>and others do). How can I get it to bind to a port and listen? I did >>>specify my external ip in the mpd.links file. On an unrelated note, if i >>>start mpd and run 'show link', i get the following: >>> >>> > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-net" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 1 1:58: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D13E337B400 for ; Mon, 1 Jul 2002 01:58:00 -0700 (PDT) Received: from www.example.org (dhcp-nic-val-26-106.cisco.com [64.103.26.106]) by mx1.FreeBSD.org (Postfix) with SMTP id 56B7743E0A for ; Mon, 1 Jul 2002 01:57:54 -0700 (PDT) (envelope-from molter@tin.it) Received: (qmail 27327 invoked by uid 1000); 1 Jul 2002 08:57:51 -0000 Message-ID: <20020701085751.27326.qmail@cobweb.example.org> Date: Mon, 1 Jul 2002 10:57:50 +0200 From: Marco Molteni To: freebsd-net@FreeBSD.org Subject: Re: Skinny (SCCP) protocol gateway for libalias In-Reply-To: <1025480857.48597.33.camel@shumai.marcuscom.com> References: <1025480857.48597.33.camel@shumai.marcuscom.com> X-Mailer: Sylpheed version 0.7.8claws (GTK+ 1.2.10; i386-portbld-freebsd4.6) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 30 Jun 2002 19:47:37 -0400, Joe Marcus Clarke wrote: > I've written a Skinny (the call setup protocol used by Cisco IP > phones) NAT ALG for libalias. I sent the code to ru for review, but > he's too busy. He wondered how any others would find it useful. > > Basically, it allows Cisco IP phones behind a FreeBSD running natd or > ppp to communicate correctly with a public Cisco Call Manager. It is > based on sniffer decodes from ethereal, and has been working for me > for some time. [..] I'd love it :-) Marco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 1 2:54:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3B7137B400 for ; Mon, 1 Jul 2002 02:54:11 -0700 (PDT) Received: from smtp07.wxs.nl (smtp07.wxs.nl [195.121.6.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8689843E09 for ; Mon, 1 Jul 2002 02:54:10 -0700 (PDT) (envelope-from Peter.Blok@inter.NL.net) Received: from bsdpc ([80.60.248.65]) by smtp07.wxs.nl (Netscape Messaging Server 4.15) with ESMTP id GYKE6702.LXM for ; Mon, 1 Jul 2002 11:54:07 +0200 From: "Peter J. Blok" To: freebsd-net@freebsd.org Subject: mpd netgraph pptp server Date: Mon, 1 Jul 2002 10:22:13 +0200 User-Agent: KMail/1.4.1 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_1X9KWS7IL37ZUWTQVY8I" Message-Id: <200207011022.13398.Peter.Blok@inter.NL.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --------------Boundary-00=_1X9KWS7IL37ZUWTQVY8I Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Hi, I have a gateway/firewall which is the spider in the web for different IP segments. From two segments 192.168.2.0/24 and 192.168.10.0/24 I am trying to setup PPTP tunnels. I have two different pptp sections (pptp1 and pptp2) in both mpd.conf and mpd.links with unique names. Each pptp section has its own "pptp self" listen address. The problem is that the mpd daemon only listens on the first pptp (pptp1) section and doesn't listen on the 2nd (pptp2). When I load pptp2 first before pptp1 it is the other way around. I am using sockstat -l to confirm where mpd is listening on? Am I doing something wrong here? See attachments Thx, Peter --------------Boundary-00=_1X9KWS7IL37ZUWTQVY8I Content-Type: text/plain; charset="us-ascii"; name="mpd.conf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mpd.conf" default: load pptp1 load pptp2 pptp1: new -i ng1 pptp1 pptp1 log +auth +ccp +chat +fsm +iface +pptp +ipcp +lcp +link +phys set iface disable on-demand set iface enable proxy-arp set iface idle 0 set bundle disable multilink set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 10 60 set ipcp yes vjcomp set ipcp ranges 192.168.10.1/32 192.168.10.2/32 set ipcp dns 192.168.1.1 set ipcp nbns 192.168.1.135 set bundle enable compression set ccp yes mppc pptp2: new -i ng2 pptp2 pptp2 log +auth +ccp +chat +fsm +iface +pptp +ipcp +lcp +link +phys set iface disable on-demand set iface enable proxy-arp set iface idle 0 set bundle disable multilink set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 10 60 set ipcp yes vjcomp set ipcp ranges 192.168.2.1/32 192.168.2.2/32 set ipcp dns 192.168.2.1 set ipcp nbns 192.168.2.1 set bundle enable compression set ccp yes mppc --------------Boundary-00=_1X9KWS7IL37ZUWTQVY8I Content-Type: text/plain; charset="us-ascii"; name="mpd.links" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mpd.links" pptp1: set link type pptp set pptp self 192.168.10.1 set pptp enable incoming set pptp disable originate pptp2: set link type pptp set pptp self 192.168.2.1 set pptp enable incoming set pptp disable originate --------------Boundary-00=_1X9KWS7IL37ZUWTQVY8I-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 1 4:33:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5616B37B400 for ; Mon, 1 Jul 2002 04:33:19 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with SMTP id 0F7B043E0A for ; Mon, 1 Jul 2002 04:33:18 -0700 (PDT) (envelope-from oppermann@pipeline.ch) Received: (qmail 32855 invoked from network); 1 Jul 2002 11:32:19 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 1 Jul 2002 11:32:19 -0000 Message-ID: <3D203DAC.B32AF1A8@pipeline.ch> Date: Mon, 01 Jul 2002 13:31:56 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: net@freebsd.org Subject: Re: ipflow_has ? References: <20020629053430.A70505@iguana.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Luigi Rizzo wrote: > > Hi, > looking at the code in ip_flow.c, i notice that the hash > function ipflow_hash() uses both the source and destination > address as parameters, and additionally, it never considers > the lower two bits of the destination addres. The code is below, > IPFLOW_HASHBITS is 6: > > unsigned hash = tos; > int idx; > for (idx = 0; idx < 32; idx += IPFLOW_HASHBITS) > hash += (dst.s_addr >> (32 - idx)) + (src.s_addr >> idx); > return hash & (IPFLOW_HASHSIZE-1); > > Of course it is just an optimization, but shouldn't routing > decisions be based on the dst address only ? Routing decisions yes. But ipflow is about flows. And flows are from one IP to another. This is why both is being hashed. > Just using the dst address would slightly simplify the function, > and especially has the potential of collapsing a lot of information > in the ipflow cache -- consider the case of a router box in front > of a busy web server. If you change that please rename it to route_cache or so but no it shouldn't be called ipflow anymore then. This caching only helps in an Intranet where you have only a handful of routes. If you do Internet routing with many destinations or you have a full view then it'll make the routing slower because it is busting/cycling the cache all the time. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 1 4:35:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5A7637B400 for ; Mon, 1 Jul 2002 04:35:41 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with SMTP id 9EE9043E1A for ; Mon, 1 Jul 2002 04:35:40 -0700 (PDT) (envelope-from oppermann@pipeline.ch) Received: (qmail 33215 invoked from network); 1 Jul 2002 11:34:43 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 1 Jul 2002 11:34:43 -0000 Message-ID: <3D203E3B.F8F91B9B@pipeline.ch> Date: Mon, 01 Jul 2002 13:34:19 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: net@freebsd.org Subject: Re: Should we keep a cache of mbuf+cluster ready for use ? References: <20020629145303.A75543@iguana.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Luigi Rizzo wrote: > > Hi, > during some experiments i was doing recently, i noticed that there > is a significant improvement in the forwarding speed (especially > at very high speeds) if we keep a small pool of mbuf+cluster > ready for use. This is because most network drivers do something > like this > > MGETHDR(m_new, M_DONTWAIT, MT_DATA); > if (m_new == NULL) > return(ENOBUFS); > > MCLGET(m_new, M_DONTWAIT); > if (!(m_new->m_flags & M_EXT)) { > m_freem(m_new); > return(ENOBUFS); > } > > when replenishing the receive buffers, and both macros are quite > long even if there are available blocks in the free lists. We can > store buffers of this form when/if they are released with some code > like this: > > if (my_pool_count < my_pool_max && m->m_next == NULL && > (m->m_flags & M_EXT) && M_EXT_WRITABLE(m) ) { > m->m_nextpkt = my_pool; > m->m_data = ->m_ext.ext_buf; > m->m_len = m->m_pkthdr.len = MCLBYTES; > my_pool = m; > my_pool_now++; > } else { > ... rest of m_freem() ... > } > > and save a lot of overhead (we just need to reset m_data and > m_len and m_pkthdr.len) when someone wants to allocate them. > > Is there interest in committing some code like this to > mbuf.h and maybe uipc_mbuf*.c ? Sounds good to me. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 1 4:37:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEA2437B400 for ; Mon, 1 Jul 2002 04:37:21 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with SMTP id 6A4E543E26 for ; Mon, 1 Jul 2002 04:37:20 -0700 (PDT) (envelope-from oppermann@pipeline.ch) Received: (qmail 33497 invoked from network); 1 Jul 2002 11:36:22 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 1 Jul 2002 11:36:22 -0000 Message-ID: <3D203E9F.D9CFA13D@pipeline.ch> Date: Mon, 01 Jul 2002 13:35:59 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeffrey Hsu Cc: Luigi Rizzo , net@freebsd.org Subject: Re: Should we keep a cache of mbuf+cluster ready for use ? References: <0GYH00JJCOL3HO@mta7.pltn13.pbi.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Jeffrey Hsu wrote: > > So, what you want is something like a > MGETHCL(m, how, type) > MHCLFREE(m) > interface which first looks in a combined freelist before the individual > mbuf and cluster freelists. I think it's a good idea. There should be per CPU queues as in kmalloc for SMP. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 1 6:36:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 393E937B406 for ; Mon, 1 Jul 2002 06:36:31 -0700 (PDT) Received: from web.cs.ndsu.nodak.edu (web.cs.ndsu.NoDak.edu [134.129.125.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAB4543E0A for ; Mon, 1 Jul 2002 06:36:30 -0700 (PDT) (envelope-from tinguely@web.cs.ndsu.nodak.edu) Received: (from tinguely@localhost) by web.cs.ndsu.nodak.edu (8.11.4/8.11.4) id g61DaTW63890; Mon, 1 Jul 2002 08:36:29 -0500 (CDT) (envelope-from tinguely) Date: Mon, 1 Jul 2002 08:36:29 -0500 (CDT) From: mark tinguely Message-Id: <200207011336.g61DaTW63890@web.cs.ndsu.nodak.edu> To: rizzo@icir.org Subject: Re: Should we keep a cache of mbuf+cluster ready for use ? Cc: net@FreeBSD.ORG In-Reply-To: <3D203E3B.F8F91B9B@pipeline.ch> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Luigi Rizzo wrote: > during some experiments i was doing recently, i noticed that there > is a significant improvement in the forwarding speed (especially > at very high speeds) if we keep a small pool of mbuf+cluster > ready for use. I did this a few years back with an IDT NICsTAR ATM driver. I had a privately allocated/managed chunk of memory that held MBUFs and external cluster data. I made it contiguous which is over-kill. The idea was the IDT device needed to load the external buffers into the recieve port. I did not want to waste the time allocating a MBUF, freeing the MBUF only to allocate again. I can pre-index packet header and the DMA address to take care of any expected headers. If the MBUF was allocated when the the buffer was placed into the DMA recieve queue, when the PDU was complete, we could immediately shove the MBUF/cluster into the network stack. when the network stack released the packet, a new flag on the MBUF, which I called M_PERM, signaled the free code to not break the MBUF/cluster association. Then MBUF/cluster combination was programmed into the ATM recieve buffer. (the cluster was the physical address for DMA, the MBUF was the virtual return address returned by the interrupt complete code). --mark tinguely To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 1 7:49:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A21B537B494 for ; Mon, 1 Jul 2002 07:49:29 -0700 (PDT) Received: from mail.toltecint.net (mail.toltecint.net [65.45.180.172]) by mx1.FreeBSD.org (Postfix) with SMTP id 373D743E0A for ; Mon, 1 Jul 2002 07:49:28 -0700 (PDT) (envelope-from arthur.peet@toltec.biz) Received: (qmail 67841 invoked by uid 85); 1 Jul 2002 14:49:27 -0000 Received: from artslaptop.toltecint.net (HELO ARTSLAPTOP.toltec.biz) (192.168.135.20) by mail.toltecint.net with SMTP; 1 Jul 2002 14:49:24 -0000 Message-Id: <5.1.1.6.2.20020628085502.00a6bf08@mail.toltecint.net> X-Sender: art@mail.toltecint.net X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 01 Jul 2002 08:49:14 -0600 To: Julian Elischer From: Arthur Peet Subject: Re: bpf/netgraph interaction Cc: freebsd-net@FreeBSD.ORG In-Reply-To: References: <5.1.1.6.2.20020627170548.0220fb38@mail.toltecint.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Julian, Thanks for your assistance. My understanding of the use and power of netgraph is much improved. Your first response to my question (Go to the source, ...), gave me the idea to filter the response "from" the process which was using BPF for it's read and write operations. This was done in hope the BPF injection also occurred before netgraph hook for the transactions to the interface (again, I was not able to prove this in the source). This gave me the result I was looking for. Thanks again, Art At 05:20 PM 6/27/2002, Julian Elischer wrote: >Ipfw divers from within the IP stack >by then it's too late. > >you could diver th epackets using netgraph and filter them and then >pass them back into the eiface netgraph node to continue up. > >then you tell your application to listen to the "nge" >interface.. unfortunatly another driver also produces 'nge' interfaces, >but the chance you have htat card is quite small. > > > >[fxp0]<--->[ng_ether]<----->{filter}<--->ng_eiface<---->[IP stack] > \ > \---BPF > > > > > > > >On Thu, 27 Jun 2002, Arthur Peet wrote: > > > At 04:50 PM 6/27/2002, Julian Elischer wrote: > > > > Are there any other taps I may access in order to accomplish this goal? > > > > > >I forget the goal. sorry > > > > > > > > No problem - Hope you don't mind if I restate it. > > I am trying to strip/drop packets before they reach a server process > which uses > > BPF for communicating with the network interface. > > I have briefly been looking into using an ipfw/divert socket, but I don't > > think that is > > going to work either. > > > > Thanks again! > > -Art > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 1 13:11: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04BF537B400 for ; Mon, 1 Jul 2002 13:11:06 -0700 (PDT) Received: from garbo.lodgenet.com (garbo.lodgenet.com [204.124.122.252]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49EB543E09 for ; Mon, 1 Jul 2002 13:11:05 -0700 (PDT) (envelope-from lmckenna@lodgenet.com) Received: from hardy.lodgenet.com (hardy.lodgenet.com [10.0.104.235]) by garbo.lodgenet.com (8.11.4/8.11.4) with ESMTP id g61Jn7c13011; Mon, 1 Jul 2002 14:49:07 -0500 (CDT) Received: from chaplin.lodgenet.com (not verified[10.0.104.215]) by hardy.lodgenet.com with MailMarshal (4,2,5,0) id ; Mon, 01 Jul 2002 14:49:07 -0500 Received: by chaplin.lodgenet.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 14:44:33 -0500 Message-ID: <3EA88113DE92D211807300805FA7994209149EF6@chaplin.lodgenet.com> From: "McKenna, Lee" To: "'freebsd-net@freebsd.org'" Cc: "'wpaul@windriver.com'" Subject: RE: bge problem under 4.6-stable Date: Mon, 1 Jul 2002 14:44:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I replaced the 3com 3c996B-T nics (bge driver) with Asante 1000TPC nics (nge driver) and now nfs works just fine. Apparently there is something wrong either with these 3com nics or with the bge driver when using nfs under 4.6-STABLE (as of a cvsup and make world this morning 7/1). --Lee > -----Original Message----- > From: McKenna, Lee > Sent: Thursday, June 27, 2002 11:13 AM > To: 'freebsd-net@freebsd.org' > Subject: bge problem under 4.6-stable > > > I have two machines with new 3Com 3C996B-T adapters using the > bge0 driver and I am having a problem with nfs. I can mount > the server from the client, and I can cd into the mounted > directory, but as soon as I do an 'ls' command, the client > appears to hang. Strange loooking packets occasionally show > up in tcpdump with what appears to be huge, invalid port > numbers and the packets appear to be fragments?. > > I can ftp to/from the server just fine. > > I tried changing ETHER_ALIGN to 0, but same results. Tried > media 100baseTX to force both cards to 100Mbps, same results. > I removed the gigabit switch and used a crossover cable > between the 2 machines, same results. > > I removed the bge0 cards and put in good ol' reliable fxp0 > cards using same crossover cable and everything works fine. > > Is the bge driver a complete piece of crap, or am I holding > the mouse wrong? :) > > Any recommendations for a more stable GigE card over copper? > > --Lee > > Lee McKenna > Sr. Systems Engineer > LodgeNet Entertainment Coporation > 3900 West Innovation Street > Sioux Falls, SD 57107 > > 605-988-1320 > lee.mckenna@lodgenet.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 1 14: 0:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAF5237B400; Mon, 1 Jul 2002 14:00:22 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E04843E09; Mon, 1 Jul 2002 14:00:21 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.3/8.12.2) with ESMTP id g61Kw76I055380; Mon, 1 Jul 2002 22:58:07 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Doug Barton Cc: freebsd-hackers@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: ftp and mail much slower into fbsd 4.4 vs and old BSDi In-Reply-To: Your message of "Mon, 01 Jul 2002 13:50:07 PDT." <20020701134833.E24940-100000@zoot.corp.yahoo.com> Date: Mon, 01 Jul 2002 22:58:07 +0200 Message-ID: <55379.1025557087@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message <20020701134833.E24940-100000@zoot.corp.yahoo.com>, Doug Barton writ es: >On Mon, 1 Jul 2002, Terry Lambert wrote: > >> Mike Silbersack wrote: >> > On Mon, 1 Jul 2002, Doug Barton wrote: >> > > The problem is that Terry has described the theory, whereas many of us >> > > who have observed the situation in the real world have noticed that even >> > > on a homogenous network (all with newreno enabled) performance is still >> > > worse than with newreno disabled. >> >> I guess you missed the part where I said that FreeBSD had bugs, and >> Matt Dillon posted patches? > >Nope. I think you missed the part where I said I was talking about >reality, not theory. :) The reality is, it's broken now, and in my >experience, turning it off makes the system "work better." Yes, I can attest to this an I belive it is actually the case on both -current and -releng4 that disabling newreno improves TCP performance. I belive running an X11 application or scp(1) over a wavelan is a very good test-bed for this issue. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 1 14: 7:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7853037B400 for ; Mon, 1 Jul 2002 14:07:23 -0700 (PDT) Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by mx1.FreeBSD.org (Postfix) with SMTP id 96CE443E2F for ; Mon, 1 Jul 2002 14:07:22 -0700 (PDT) (envelope-from kudzu@tenebras.com) Received: (qmail 3824 invoked from network); 1 Jul 2002 21:07:21 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (66.92.188.241) by 0 with SMTP; 1 Jul 2002 21:07:21 -0000 Message-ID: <3D20C489.5040108@tenebras.com> Date: Mon, 01 Jul 2002 14:07:21 -0700 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020626 X-Accept-Language: en-us, en, fr-fr, ru MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Doug Barton , freebsd-hackers@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: ftp and mail much slower into fbsd 4.4 vs and old BSDi References: <55379.1025557087@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Poul-Henning Kamp wrote: > Yes, I can attest to this an I belive it is actually the case on both > -current and -releng4 that disabling newreno improves TCP performance. > > I belive running an X11 application or scp(1) over a wavelan is a very > good test-bed for this issue. Wireless breaks a lot of "optimizations," doesn't it? Congestion control assumes that packet loss is due to congestion, and less than 1% of loss is due to damage -- quite the opposite of 802.11(b) in an urban environment -- cordless phones, microwaves, etc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 1 14:14: 1 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EF4E37B400; Mon, 1 Jul 2002 14:13:56 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id D301443E0A; Mon, 1 Jul 2002 14:13:55 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.3/8.12.2) with ESMTP id g61LBg6I057970; Mon, 1 Jul 2002 23:11:42 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Michael Sierchio Cc: Doug Barton , freebsd-hackers@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: ftp and mail much slower into fbsd 4.4 vs and old BSDi In-Reply-To: Your message of "Mon, 01 Jul 2002 14:07:21 PDT." <3D20C489.5040108@tenebras.com> Date: Mon, 01 Jul 2002 23:11:42 +0200 Message-ID: <57969.1025557902@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message <3D20C489.5040108@tenebras.com>, Michael Sierchio writes: >Poul-Henning Kamp wrote: > >> Yes, I can attest to this an I belive it is actually the case on both >> -current and -releng4 that disabling newreno improves TCP performance. >> >> I belive running an X11 application or scp(1) over a wavelan is a very >> good test-bed for this issue. > >Wireless breaks a lot of "optimizations," doesn't it? Congestion control >assumes that packet loss is due to congestion, and less than 1% of loss >is due to damage -- quite the opposite of 802.11(b) in an urban >environment -- cordless phones, microwaves, etc. newreno is not sold as being a significant pessimization in some cases. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 1 14:27: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C42A37B400; Mon, 1 Jul 2002 14:27:06 -0700 (PDT) Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6F8E43E0A; Mon, 1 Jul 2002 14:27:04 -0700 (PDT) (envelope-from brian@FreeBSD.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [IPv6:fec0::1:12]) by Awfulhak.org (8.12.5/8.12.5) with ESMTP id g61LQvpb002136; Mon, 1 Jul 2002 22:26:57 +0100 (BST) (envelope-from brian@FreeBSD.org) Received: from hak.lan.Awfulhak.org (brian@localhost [IPv6:::1]) by hak.lan.Awfulhak.org (8.12.5/8.12.5) with SMTP id g61LQuuH008525; Mon, 1 Jul 2002 22:26:56 +0100 (BST) (envelope-from brian@FreeBSD.org) Date: Mon, 1 Jul 2002 22:26:56 +0100 From: Brian Somers To: Cc: net@FreeBSD.org, Brian@FreeBSD.org Subject: Re: Issues with pppoe & FBSD 4.6 Message-Id: <20020701222656.32aeab57.brian@FreeBSD.org> In-Reply-To: <1329.216.170.184.18.1025039591.squirrel@www.soho.berbee.com> References: <1329.216.170.184.18.1025039591.squirrel@www.soho.berbee.com> X-Mailer: Sylpheed version 0.7.8claws (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, The problem has now been fixed. It was caused because of a bug in ppp where it would only read at most one netgraph message per second. The additional (unused) message was adding another second - pushing things over the edge. You can either get the latest ppp from http://www.Awfulhak.org/~brian, or upgrade to the latest -stable or -current to fix the problem. Oh, and my apologies for the amount of time it took to fix :( On Tue, 25 Jun 2002 16:13:11 -0500 (CDT), rob@the-rob.com wrote: > Any progress on this? Just curious. My fbsd box has been down for the > last 36 hours. Until yesterday it would be down for 8-10 hours then come > up from 16-24. Yesterday it went down at ~8:30 am and has been down > since. I left it try and grab IP information but it just "session closed" > error (and created a shit load of logs). > > > I copied my config files from my firewall and attempted to make one of my 2 > other fbsd boxes my firewall and connect up to the pppoe server but they > had the same thing (timeout...Generic "session closed" errors). So it's > definatly a fbsd issue. > > Just wondering on the status...roomates are kinda getting ansy about > getting the internet connection up and stable, after being up and down for > about a week. > > > rwz > > -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 1 15: 6: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 941B337B400; Mon, 1 Jul 2002 15:05:58 -0700 (PDT) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF57343E0A; Mon, 1 Jul 2002 15:05:57 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (#6@localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.12.5/8.12.5) with ESMTP id g61M5t0L008698; Mon, 1 Jul 2002 18:05:55 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200207012205.g61M5t0L008698@whizzo.transsys.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Poul-Henning Kamp Cc: Doug Barton , freebsd-hackers@FreeBSD.ORG, net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: ftp and mail much slower into fbsd 4.4 vs and old BSDi References: <55379.1025557087@critter.freebsd.dk> In-reply-to: Your message of "Mon, 01 Jul 2002 22:58:07 +0200." <55379.1025557087@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Jul 2002 18:05:55 -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > Yes, I can attest to this an I belive it is actually the case on both > -current and -releng4 that disabling newreno improves TCP performance. > > I belive running an X11 application or scp(1) over a wavelan is a very > good test-bed for this issue. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 I find this patch also improves performance of SSH on most network media. Why so many applications go to the trouble to disable Nagle's algorithm is beyond me. I suspect the socket option has too seductive of a name. louie Index: packet.c =================================================================== RCS file: /a/cvs/src/crypto/openssh/packet.c,v retrieving revision 1.1.1.1.2.4 diff -u -r1.1.1.1.2.4 packet.c --- packet.c 28 Sep 2001 01:33:34 -0000 1.1.1.1.2.4 +++ packet.c 2 Apr 2002 18:26:41 -0000 @@ -1281,9 +1281,11 @@ error("setsockopt IPTOS_LOWDELAY: %.100s", strerror(errno)); } +#if 0 if (setsockopt(connection_in, IPPROTO_TCP, TCP_NODELAY, (void *) &on, sizeof(on)) < 0) error("setsockopt TCP_NODELAY: %.100s", strerror(errno)); +#endif } else if (packet_connection_is_ipv4()) { /* * Set IP options for a non-interactive connection. Use To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 1 16:39:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF46237B400; Mon, 1 Jul 2002 16:39:32 -0700 (PDT) Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 696FF43E0A; Mon, 1 Jul 2002 16:39:30 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g61NcRu5048364; Mon, 1 Jul 2002 19:38:28 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200207012205.g61M5t0L008698@whizzo.transsys.com> References: <55379.1025557087@critter.freebsd.dk> <200207012205.g61M5t0L008698@whizzo.transsys.com> Date: Mon, 1 Jul 2002 19:38:26 -0400 To: "Louis A. Mamakos" From: Garance A Drosihn Subject: Re: ftp and mail much slower into fbsd 4.4 vs and old BSDi Cc: freebsd-hackers@FreeBSD.ORG, net@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 6:05 PM -0400 7/1/02, Louis A. Mamakos wrote: > >Why so many applications go to the trouble to disable Nagle's >algorithm is beyond me. I suspect the socket option has too >seductive of a name. I suspect someone had a specific case where Nagle's algorithm causes a real problem. They turn on TCP_NODELAY for that situation, see a huge improvement, and assume that it is a good idea to always turn on TCP_NODELAY. We had one case here were reloading a MOO database through a network connection took something like 5 hours. Turning on TCP_NODELAY reduced the time to about 10 minutes. We got all excited about that, and tried TCP_NODELAY in a number of other situations in the same MOO. In all other cases the option either hurt performance or did not help it enough to care about... -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 1 20:53:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6779837B400 for ; Mon, 1 Jul 2002 20:53:32 -0700 (PDT) Received: from scout.networkphysics.com (fw.networkphysics.com [205.158.104.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB6E343E13 for ; Mon, 1 Jul 2002 20:53:31 -0700 (PDT) (envelope-from pavel@networkphysics.com) Received: from NetworkPhysics.COM (gt500.fractal.networkphysics.com [10.10.0.192]) by scout.networkphysics.com (8.11.5/8.11.5) with ESMTP id g623rUR62985 for ; Mon, 1 Jul 2002 20:53:31 -0700 (PDT) Message-Id: <200207020353.g623rUR62985@scout.networkphysics.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 X-Exmh-Isig-CompType: unknown X-Exmh-Isig-Folder: inbox To: net@FreeBSD.ORG Subject: questions about TCP RST validity Reply-To: pavel@alum.mit.edu X-Face: 3Y45fK2P',OZ{p{%jFQfsYLQA)-,d1K+cx@v"K(1.9^"Cx-J*93m!X9nsl*8C\'.tt} ;X+GO]HCw8n=+Dn Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi. I'm confused about some code dealing with the acceptance of RSTs in tcp_input.c. I've gleaned what I can about the history of that code through the CVS repository, but I'm still looking for some more insight. The code in question requires that a RST have a sequence number within the current advertised window: if (thflags & TH_RST) { if (SEQ_GEQ(th->th_seq, tp->last_ack_sent) && SEQ_LT(th->th_seq, tp->last_ack_sent + tp->rcv_wnd)) { switch (tp->t_state) { case TCPS_SYN_RECEIVED: ... } } goto drop; } This is all well and good. It follows RFC793 which says: In all states except SYN-SENT, all reset (RST) segments are validated by checking their SEQ-fields. A reset is valid if its sequence number is in the window. This prevents DoS attacks by requiring an intruder to guess a seqnum within the current window. (The code appeared with revs 1.81 and 1.98, responding to PR kern/7892 which concerned such DoS attacks.) However, it seems to ignore the possibility that the RST and an ACK updating the advertised window might cross in flight. RFC793 also requires that RSTs set their seqnum from the ACK field of the pkt they are responding to, even if the sender knows it has sent a seqnum beyond that ACK (like the FIN below). Here is a trace to illustrate: 09:05:35.214014 BB.61390 > AA.80: S 2597110672:2597110672(0) win 65535 09:05:35.214310 AA.80 > BB.61390: S 3568521185:3568521185(0) ack 2597110673 win 4380 (DF) 09:05:35.277441 BB.61390 > AA.80: . ack 3568521186 win 65535 09:05:35.278316 BB.61390 > AA.80: P 2597110673:2597111260(587) ack 3568521186 win 65535 09:05:35.302557 AA.80 > BB.61390: P 3568521186:3568522646(1460) ack 2597111260 win 4380 (DF) 09:05:35.302659 AA.80 > BB.61390: P 3568522646:3568524106(1460) ack 2597111260 win 4380 (DF) 09:05:35.302762 AA.80 > BB.61390: P 3568524106:3568525566(1460) ack 2597111260 win 4380 (DF) 09:05:35.380157 BB.61390 > AA.80: . ack 3568524106 win 64240 09:05:35.380211 AA.80 > BB.61390: . 3568525566:3568527026(1460) ack 2597111260 win 4380 (DF) 09:05:35.380231 AA.80 > BB.61390: . 3568527026:3568528486(1460) ack 2597111260 win 4380 (DF) 09:05:35.380248 AA.80 > BB.61390: . 3568528486:3568529946(1460) ack 2597111260 win 4380 (DF) 09:05:35.451495 BB.61390 > AA.80: . ack 3568527026 win 64240 09:05:35.451537 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111260 win 4380 (DF) 09:05:35.451552 AA.80 > BB.61390: . 3568531406:3568532866(1460) ack 2597111260 win 4380 (DF) 09:05:35.451571 AA.80 > BB.61390: . 3568532866:3568534326(1460) ack 2597111260 win 4380 (DF) 09:05:35.453172 BB.61390 > AA.80: . ack 3568529946 win 62780 09:05:35.453206 AA.80 > BB.61390: . 3568534326:3568535786(1460) ack 2597111260 win 4380 (DF) 09:05:35.453221 AA.80 > BB.61390: . 3568535786:3568537246(1460) ack 2597111260 win 4380 (DF) 09:05:35.453976 BB.61390 > AA.80: F 2597111260:2597111260(0) ack 3568529946 win 65535 09:05:35.454002 AA.80 > BB.61390: . 3568537246:3568537538(292) ack 2597111261 win 4380 (DF) 09:05:35.518444 BB.61390 > AA.80: R 2597111260:2597111260(0) win 0 09:05:35.956066 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF) 09:05:36.961787 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF) 09:05:38.973207 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF) 09:05:42.996062 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF) 09:05:51.041749 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF) 09:06:05.689800 AA.80 > BB.61390: . ack 2597111261 win 4380 09:06:07.133106 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF) 09:06:35.861159 AA.80 > BB.61390: . ack 2597111261 win 4380 09:06:39.315883 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF) 09:07:06.032500 AA.80 > BB.61390: . ack 2597111261 win 4380 09:07:11.498638 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF) 09:07:36.203832 AA.80 > BB.61390: . ack 2597111261 win 4380 09:07:43.681378 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF) 09:08:06.375192 AA.80 > BB.61390: . ack 2597111261 win 4380 09:08:15.864135 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF) 09:08:36.546533 AA.80 > BB.61390: . ack 2597111261 win 4380 09:08:48.046904 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF) 09:09:06.717897 AA.80 > BB.61390: . ack 2597111261 win 4380 09:09:20.229640 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF) 09:09:36.889228 AA.80 > BB.61390: . ack 2597111261 win 4380 09:09:52.412413 AA.80 > BB.61390: R 3568537538:3568537538(0) ack 2597111261 win 4380 (DF) Now, it seems to me that one could argue that the fault is entirely on BB, who fails to respond with RST to all the pkts sent after the initial RST. I imagine that this could be caused by some sort of stateful firewall, or perhaps by BB hanging up a dialup connection. This case is alluded to in the tcp_input.c comments: * If we have multiple segments in flight, the intial reset * segment sequence numbers will be to the left of last_ack_sent, * but they will eventually catch up. In any event, though, it seems to me relatively harmless to have AA accept seqnums "slightly" to the left of its current advertised window (say last_ack_sent - rcv_wnd). This would save a bunch of needless retransmits and it would clean up the control block much sooner than letting AA timeout on retransmitting. What collective wisdom do folks have about this? Tom Pavel Network Physics pavel@networkphysics.com / pavel@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 1 21:48:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E0B037B400 for ; Mon, 1 Jul 2002 21:48:50 -0700 (PDT) Received: from out1.mx.nwbl.wi.voyager.net (out1.mx.nwbl.wi.voyager.net [169.207.3.119]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9607543E0A for ; Mon, 1 Jul 2002 21:48:49 -0700 (PDT) (envelope-from silby@silby.com) Received: from pop0.nwbl.wi.voyager.net (pop0.nwbl.wi.voyager.net [169.207.1.115]) by out1.mx.nwbl.wi.voyager.net (8.12.3/8.11.4/1.7) with ESMTP id g624mmiB019101; Mon, 1 Jul 2002 23:48:48 -0500 Received: from [10.1.1.6] (d185.as13.nwbl0.wi.voyager.net [169.207.136.251]) by pop0.nwbl.wi.voyager.net (8.10.2/8.10.2) with ESMTP id g624mlX48475; Mon, 1 Jul 2002 23:48:47 -0500 (CDT) Date: Mon, 1 Jul 2002 23:51:42 -0500 (CDT) From: Mike Silbersack To: pavel@alum.mit.edu Cc: net@FreeBSD.ORG Subject: Re: questions about TCP RST validity In-Reply-To: <200207020353.g623rUR62985@scout.networkphysics.com> Message-ID: <20020701234858.G87544-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 1 Jul 2002, Tom Pavel wrote: > Here is a trace to illustrate: > > 09:05:35.956066 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF) > 09:05:36.961787 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF) > 09:05:38.973207 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111261 win 4380 (DF) Is this a real trace? It looks highly irregular to me. I don't see why BB isn't RSTing each packet, and AA looks to be retransmitting way too quickly. > In any event, though, it seems to me relatively harmless to have AA > accept seqnums "slightly" to the left of its current advertised window > (say last_ack_sent - rcv_wnd). This would save a bunch of needless > retransmits and it would clean up the control block much sooner than > letting AA timeout on retransmitting. > > What collective wisdom do folks have about this? > > > Tom Pavel I'm not sure doubling the "RST window" is a good idea. With window sizes increasing as they are, that could become a significant issue as time goes on. How about one MSS worth of window or something similar? Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 2 0:10:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E914E37B400 for ; Tue, 2 Jul 2002 00:10:50 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4E8743E0A for ; Tue, 2 Jul 2002 00:10:50 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g627AoZ02468; Tue, 2 Jul 2002 00:10:50 -0700 (PDT) (envelope-from rizzo) Date: Tue, 2 Jul 2002 00:10:50 -0700 From: Luigi Rizzo To: net@freebsd.org Subject: Mbuf allocator performance (was Should we keep a cache of mbuf+cluster ready for use ?) Message-ID: <20020702001050.B2250@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [Bcc to -current as relevant there] As a followup to my question below, i did some simple experiment on a -current box acting as a router, using two "em" cards and DEVICE_POLLING (just for stability). The whole of the code is basically below -- the receiving side tries to grab the mbuf+cluster from the free pool first, and falls back to the standard method on failure; the sending side tries to attach the freed buffer to the free pool if it is the case. There is a simplification here with respect to what could go into an m_freem()/mgethdr_cluster() pair because the driver is already holding a lock, on Giant in this case, so you do not need further locking. Still, to come to the data points: CURRENT STABLE (*) fastfwd=1, pool_max=0 276kpps 365 kpps fastfwd=1, pool_max=50 355kpps 383 kpps fastfwd=0, pool_max=0 195 pps 142 kpps fastfwd=0, pool_max=50 227 kpps 146 kpps (*) This version of STABLE that I am using for comparison has some proprietary optimizations which make it a bit faster than normal. However it still uses the old ipfw code, which is invoked when fastfwd=0, and is significantly slower than the new one. Now this really seems to call for adding this interface into the mbuf subsystem. I believe we have to find a name for the allocator (the deallocator might well go into m_freem(), depending on how we implement the locking) and whether it makes sense to lock mgethdr_cluster() under per-cpu locks or under Giant, or even let the caller make sure that it holds the proper lock before trying to invoke the procedure (as i expect the "producers" or "consumers" of these pairs to be located in the network stack, chances are that they already hold a lock on Giant). cheers luigi The code: struct mbuf *em_pool; static int em_pool_max = 50; SYSCTL_INT(_hw, OID_AUTO, em_pool_max, CTLFLAG_RW, &em_pool_max,0,"max size of mbuf pool"); static int em_pool_now; SYSCTL_INT(_hw, OID_AUTO, em_pool_now, CTLFLAG_RD, &em_pool_now,0,"Current size of mbuf pool"); ... in em_get_buf() .. if (em_pool) { mp = em_pool; em_pool = mp->m_nextpkt; em_pool_now--; goto have_it; } ... in em_clean_transmit_interrupts() ... if ((m = tx_buffer->m_head)) { if (em_pool_now < em_pool_max && m->m_next == NULL && m->m_flags & M_EXT && M_WRITABLE(m) ) { m->m_nextpkt = em_pool; em_pool = m; em_pool_now++; } else m_freem(m); tx_buffer->m_head = NULL; } On Sat, Jun 29, 2002 at 02:53:03PM -0700, Luigi Rizzo wrote: > Hi, > during some experiments i was doing recently, i noticed that there > is a significant improvement in the forwarding speed (especially > at very high speeds) if we keep a small pool of mbuf+cluster > ready for use. This is because most network drivers do something > like this > > MGETHDR(m_new, M_DONTWAIT, MT_DATA); > if (m_new == NULL) > return(ENOBUFS); > > MCLGET(m_new, M_DONTWAIT); > if (!(m_new->m_flags & M_EXT)) { > m_freem(m_new); > return(ENOBUFS); > } > > when replenishing the receive buffers, and both macros are quite > long even if there are available blocks in the free lists. We can > store buffers of this form when/if they are released with some code > like this: > > if (my_pool_count < my_pool_max && m->m_next == NULL && > (m->m_flags & M_EXT) && M_EXT_WRITABLE(m) ) { > m->m_nextpkt = my_pool; > m->m_data = ->m_ext.ext_buf; > m->m_len = m->m_pkthdr.len = MCLBYTES; > my_pool = m; > my_pool_now++; > } else { > ... rest of m_freem() ... > } > > and save a lot of overhead (we just need to reset m_data and > m_len and m_pkthdr.len) when someone wants to allocate them. > > Is there interest in committing some code like this to > mbuf.h and maybe uipc_mbuf*.c ? > > cheers > luigi > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 2 1:36:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69F6E37B400 for ; Tue, 2 Jul 2002 01:36:44 -0700 (PDT) Received: from scout.networkphysics.com (fw.networkphysics.com [205.158.104.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC7BF43E31 for ; Tue, 2 Jul 2002 01:36:43 -0700 (PDT) (envelope-from pavel@networkphysics.com) Received: from NetworkPhysics.COM (gt500.fractal.networkphysics.com [10.10.0.192]) by scout.networkphysics.com (8.11.5/8.11.5) with ESMTP id g628aBR64517; Tue, 2 Jul 2002 01:36:11 -0700 (PDT) Message-Id: <200207020836.g628aBR64517@scout.networkphysics.com> To: Mike Silbersack Cc: net@FreeBSD.ORG Subject: Re: questions about TCP RST validity In-Reply-To: Message from Mike Silbersack of "Mon, 01 Jul 2002 23:51:42 CDT." <20020701234858.G87544-100000@patrocles.silby.com> Date: Tue, 02 Jul 2002 01:36:11 -0700 From: Tom Pavel Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Mon, 1 Jul 2002, Mike Silbersack writes: > On Mon, 1 Jul 2002, Tom Pavel wrote: > > > Here is a trace to illustrate: > > > > 09:05:35.956066 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111 > 261 win 4380 (DF) > > 09:05:36.961787 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111 > 261 win 4380 (DF) > > 09:05:38.973207 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111 > 261 win 4380 (DF) > > Is this a real trace? It looks highly irregular to me. I don't see why > BB isn't RSTing each packet, and AA looks to be retransmitting way too > quickly. Yes, this is a real trace. And it is not a single fluke BB host either. If you look at enough web traces, you will eventually find such examples (it is pretty rare, though). Other OSes I was able to test show the same behavior as AA. I included my theories about the cause for BB's behavior (stateful firewall or modem hangup), but I really have no info about that. I'm not sure why you say the retrans are too quick. The 2 above are 1 sec and 2 sec, respectively. The rest continue exponentially. > > In any event, though, it seems to me relatively harmless to have AA > > accept seqnums "slightly" to the left of its current advertised window > > (say last_ack_sent - rcv_wnd). This would save a bunch of needless > > retransmits and it would clean up the control block much sooner than > > letting AA timeout on retransmitting. > > > > What collective wisdom do folks have about this? > > I'm not sure doubling the "RST window" is a good idea. With window sizes > increasing as they are, that could become a significant issue as time goes > on. How about one MSS worth of window or something similar? That sounds pretty reasonable. All of the traces I have noticed came with an "early" FIN from the web client, so even 1 byte would have been enough in those cases. One MSS sounds like a good compromise. Tom Pavel Network Physics pavel@networkphysics.com / pavel@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 2 2:33:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07DEA37B401 for ; Tue, 2 Jul 2002 02:33:40 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B53643E13 for ; Tue, 2 Jul 2002 02:33:39 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.3/8.12.3) with ESMTP id g629Yh0M006533; Tue, 2 Jul 2002 02:34:47 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Message-Id: <200207020934.g629Yh0M006533@gw.catspoiler.org> Date: Tue, 2 Jul 2002 02:34:07 -0700 (PDT) From: Don Lewis Subject: Re: questions about TCP RST validity To: pavel@alum.mit.edu Cc: net@FreeBSD.ORG In-Reply-To: <200207020353.g623rUR62985@scout.networkphysics.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 1 Jul, Tom Pavel wrote: > > Hi. I'm confused about some code dealing with the acceptance of RSTs > in tcp_input.c. I've gleaned what I can about the history of that > code through the CVS repository, but I'm still looking for some more > insight. The code in question requires that a RST have a sequence > number within the current advertised window: > > if (thflags & TH_RST) { > if (SEQ_GEQ(th->th_seq, tp->last_ack_sent) && > SEQ_LT(th->th_seq, tp->last_ack_sent + tp->rcv_wnd)) { > switch (tp->t_state) { > > case TCPS_SYN_RECEIVED: > ... > } > } > goto drop; > } > > > This is all well and good. It follows RFC793 which says: > > In all states except SYN-SENT, all reset (RST) segments are validated > by checking their SEQ-fields. A reset is valid if its sequence number > is in the window. > > This prevents DoS attacks by requiring an intruder to guess a seqnum > within the current window. (The code appeared with revs 1.81 and > 1.98, responding to PR kern/7892 which concerned such DoS attacks.) > > However, it seems to ignore the possibility that the RST and an ACK > updating the advertised window might cross in flight. RFC793 also > requires that RSTs set their seqnum from the ACK field of the pkt they > are responding to, even if the sender knows it has sent a seqnum > beyond that ACK (like the FIN below). If the implementation sending a RST isn't broken, the case of the RST and ACK crossing in flight is handled by sending another RST with an updated sequence number from the ACK that was received after the initial RST was sent, which the initial RST crossed in flight. > Here is a trace to illustrate: > > 09:05:35.214014 BB.61390 > AA.80: S 2597110672:2597110672(0) win 65535 > 09:05:35.214310 AA.80 > BB.61390: S 3568521185:3568521185(0) ack 2597110673 win 4380 (DF) > 09:05:35.277441 BB.61390 > AA.80: . ack 3568521186 win 65535 > 09:05:35.278316 BB.61390 > AA.80: P 2597110673:2597111260(587) ack 3568521186 win 65535 > 09:05:35.302557 AA.80 > BB.61390: P 3568521186:3568522646(1460) ack 2597111260 win 4380 (DF) > 09:05:35.302659 AA.80 > BB.61390: P 3568522646:3568524106(1460) ack 2597111260 win 4380 (DF) > 09:05:35.302762 AA.80 > BB.61390: P 3568524106:3568525566(1460) ack 2597111260 win 4380 (DF) > 09:05:35.380157 BB.61390 > AA.80: . ack 3568524106 win 64240 > 09:05:35.380211 AA.80 > BB.61390: . 3568525566:3568527026(1460) ack 2597111260 win 4380 (DF) > 09:05:35.380231 AA.80 > BB.61390: . 3568527026:3568528486(1460) ack 2597111260 win 4380 (DF) > 09:05:35.380248 AA.80 > BB.61390: . 3568528486:3568529946(1460) ack 2597111260 win 4380 (DF) > 09:05:35.451495 BB.61390 > AA.80: . ack 3568527026 win 64240 > 09:05:35.451537 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111260 win 4380 (DF) > 09:05:35.451552 AA.80 > BB.61390: . 3568531406:3568532866(1460) ack 2597111260 win 4380 (DF) > 09:05:35.451571 AA.80 > BB.61390: . 3568532866:3568534326(1460) ack 2597111260 win 4380 (DF) > 09:05:35.453172 BB.61390 > AA.80: . ack 3568529946 win 62780 > 09:05:35.453206 AA.80 > BB.61390: . 3568534326:3568535786(1460) ack 2597111260 win 4380 (DF) > 09:05:35.453221 AA.80 > BB.61390: . 3568535786:3568537246(1460) ack 2597111260 win 4380 (DF) > 09:05:35.453976 BB.61390 > AA.80: F 2597111260:2597111260(0) ack 3568529946 win 65535 > 09:05:35.454002 AA.80 > BB.61390: . 3568537246:3568537538(292) ack 2597111261 win 4380 (DF) > 09:05:35.518444 BB.61390 > AA.80: R 2597111260:2597111260(0) win 0 It looks like BB is broken. From the timestamps above, it looks like there is about a 60 ms RTT between AA and BB. If so, it sure looks like BB is sending the RST in response to the ACK 2597111261 from AA, but why is it using the wrong sequence number? It shouldn't be sending the RST in response to one of the earlier data packets from AA, since BB acked that data in the FIN packet that it sent. I suppose BB could have sent the RST unsolicited, but why did it wait what looks like a RTT delay time after sending the FIN? > Now, it seems to me that one could argue that the fault is entirely on > BB, who fails to respond with RST to all the pkts sent after the > initial RST. I imagine that this could be caused by some sort of > stateful firewall, or perhaps by BB hanging up a dialup connection. > This case is alluded to in the tcp_input.c comments: > > * If we have multiple segments in flight, the intial reset > * segment sequence numbers will be to the left of last_ack_sent, > * but they will eventually catch up. This comment is covers the case of the initial outgoing RST passing incoming ACK packets in flight. The only way of handling the modem being hung up is to time out the connection. BTW, if stateful firewalls don't send RST packets in response to incoming TCP packets that don't correspond to valid connections, it is much easier to spoof a connection to an outside host that looks like it is coming from the firewall. > In any event, though, it seems to me relatively harmless to have AA > accept seqnums "slightly" to the left of its current advertised window > (say last_ack_sent - rcv_wnd). This would save a bunch of needless > retransmits and it would clean up the control block much sooner than > letting AA timeout on retransmitting. This doesn't help in the above example if the initial RST is lost due to network congestion or other types of packet loss on the network. If only one RST is sent and it gets dropped before the other end of the connection sees it, we've still got the same problem. Increasing the size of the acceptable RST window increases the vulnerability to DoS attacks proportionally. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 2 3:30:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6BFE37B400 for ; Tue, 2 Jul 2002 03:30:49 -0700 (PDT) Received: from smtp.overload.org (overload.xs4all.nl [213.84.4.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2066B43E09 for ; Tue, 2 Jul 2002 03:30:49 -0700 (PDT) (envelope-from jorgen@overload.org) Received: by smtp.overload.org (Postfix, from userid 1000) id 6DC9851AC2; Tue, 2 Jul 2002 12:34:49 +0200 (CEST) Date: Tue, 2 Jul 2002 12:34:49 +0200 From: Jorgen Maas To: freebsd-net@freebsd.org Subject: Problem related to MPD Message-ID: <20020702103449.GA88663@daemon.overload.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello all, I've got an annoying problem here with MPD (3.8). I use MPD to setup a PPTP session to my adsl modem, but after (approx) 24 hours of being online my Internet connection gets slower and slower. When I try to do a traceroute or a ping I get some warning: out of buffers Then I restart MPD by issuing a mpd -bk and everything's fine again (for a while) I use the DC driver on a Kingston board. MAXUSERS=0 at the moment, I've tried increasing thie value aswell as the NMBCLUSTERS kernel options aswell as various sysctl's related to buffer sizes. Currently I'm running 4.6-p1 but I had this problem since 4.1 iirc Can this be a nic driver issue ? I cannot find more information on the web on this matter so you guys are my last resort :) Any help is greatly appreciated. With regards, Jorgen Maas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 2 5:29:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F248237B40D for ; Tue, 2 Jul 2002 05:28:51 -0700 (PDT) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC38843F22 for ; Tue, 2 Jul 2002 05:10:19 -0700 (PDT) (envelope-from bmilekic@angelica.unixdaemons.com) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.4/8.12.1) with ESMTP id g62C4P7g072162; Tue, 2 Jul 2002 08:04:25 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host bmilekic@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.4/8.12.1/Submit) id g62C4NEG072158; Tue, 2 Jul 2002 08:04:23 -0400 (EDT) (envelope-from bmilekic) Date: Tue, 2 Jul 2002 08:04:23 -0400 From: Bosko Milekic To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: Re: Mbuf allocator performance (was Should we keep a cache of mbuf+cluster ready for use ?) Message-ID: <20020702080423.A69693@unixdaemons.com> References: <20020702001050.B2250@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020702001050.B2250@iguana.icir.org>; from rizzo@icir.org on Tue, Jul 02, 2002 at 12:10:50AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org There are several problems with your "simple" code that make it simpler than what's in -CURRENT and in -STABLE and therefore yield [obviously] seemingly better times. 1) sleeping in the case of a system exhausted of mbufs and clusters is now broken because code that frees to this "combined" list will not generate wake ups; even if you build this functionality in, you would have to code the wakeup for a "special" case where one obtains both a cluster and an mbuf; it'll get complicated. 2) no per-CPU caches, you bring contention (in -CURRENT) from per-CPU back to global, which you probably don't care about now, but which will matter when Giant goes completely. 3) you violate write/read producer/consumer model. In -CURRENT, we try to not have the code doing the freeing write to any part of the mbuf, thus hopefully avoiding cache invalidation from occuring during a free that happens from a thread that doesn't usually write to the mbuf at all. I think that because of (1) and (2), especially, and because the kernel in -CURRENT is the way it is right now, you're getting better performance numbers. Try exhausting the system and seeing how far you get. I suspect you'll eventually just hang (because you'll allocate a bunch of stuff violating the real interface and then won't be able to wakeup and Do The Right Thing). While, as I said before, I agree that we should have an interface that allocates both an mbuf and a cluster, I don't think that this is the right approach. I believe that the correct approach would be to couple the mbuf and cluster allocation under a single per-CPU lock/unlock operation, which isn't too difficult to do. On Tue, Jul 02, 2002 at 12:10:50AM -0700, Luigi Rizzo wrote: > [Bcc to -current as relevant there] > > As a followup to my question below, i did some simple experiment > on a -current box acting as a router, using two "em" cards and > DEVICE_POLLING (just for stability). > > The whole of the code is basically below -- the receiving > side tries to grab the mbuf+cluster from the free pool first, > and falls back to the standard method on failure; the sending > side tries to attach the freed buffer to the free pool > if it is the case. > > There is a simplification here with respect to what could > go into an m_freem()/mgethdr_cluster() pair because the driver > is already holding a lock, on Giant in this case, so you do not need > further locking. Still, to come to the data points: > > CURRENT STABLE (*) > > fastfwd=1, pool_max=0 276kpps 365 kpps > fastfwd=1, pool_max=50 355kpps 383 kpps > > fastfwd=0, pool_max=0 195 pps 142 kpps > fastfwd=0, pool_max=50 227 kpps 146 kpps > > (*) This version of STABLE that I am using for comparison has some > proprietary optimizations which make it a bit faster than normal. > However it still uses the old ipfw code, which is invoked when > fastfwd=0, and is significantly slower than the new one. > > Now this really seems to call for adding this interface into the > mbuf subsystem. I believe we have to find a name for the allocator > (the deallocator might well go into m_freem(), depending on how we > implement the locking) and whether it makes sense to lock > mgethdr_cluster() under per-cpu locks or under Giant, or even let > the caller make sure that it holds the proper lock before trying > to invoke the procedure (as i expect the "producers" or "consumers" > of these pairs to be located in the network stack, chances are that > they already hold a lock on Giant). > > > cheers > luigi > > > The code: > > struct mbuf *em_pool; > > static int em_pool_max = 50; > SYSCTL_INT(_hw, OID_AUTO, em_pool_max, CTLFLAG_RW, > &em_pool_max,0,"max size of mbuf pool"); > static int em_pool_now; > SYSCTL_INT(_hw, OID_AUTO, em_pool_now, CTLFLAG_RD, > &em_pool_now,0,"Current size of mbuf pool"); > > ... in em_get_buf() .. > > if (em_pool) { > mp = em_pool; > em_pool = mp->m_nextpkt; > em_pool_now--; > goto have_it; > } > > ... in em_clean_transmit_interrupts() ... > if ((m = tx_buffer->m_head)) { > if (em_pool_now < em_pool_max && > m->m_next == NULL && > m->m_flags & M_EXT && > M_WRITABLE(m) ) { > m->m_nextpkt = em_pool; > em_pool = m; > em_pool_now++; > } else > m_freem(m); > tx_buffer->m_head = NULL; > } Regards, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 2 5:50:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90CF037B400 for ; Tue, 2 Jul 2002 05:50:12 -0700 (PDT) Received: from relay.wineasy.se (smtp.wineasy.se [195.42.198.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19FC543E13 for ; Tue, 2 Jul 2002 05:50:11 -0700 (PDT) (envelope-from john@veidit.net) Received: from veidit.net ([213.88.130.20]) by relay.wineasy.se with ESMTP id g62Co6Y25529 for ; Tue, 2 Jul 2002 14:50:09 +0200 Message-ID: <3D21A17C.7060607@veidit.net> Date: Tue, 02 Jul 2002 14:50:04 +0200 From: John Angelmo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: net@freebsd.org Subject: increasing throughput Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello I was thinking of cunstructing a small routerbox in my sparetime. Now since FreeBSD is my choise of OS i was thinking of a small box silent box. So how can I combine speed, size, silence and price? I was thinking of vias small buget systems (via Eden) and to that an extra intel pro 10/100 NIC Now how much can I expect in loss in throughput when selecting this system,since it is a budget system ;) Its just supposed to shuffle traffic as a router or perhaps as a gateway with a simple ipfw firewall. What extra features should I add to the kernel and are there any othere great hints? /John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 2 6: 4: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0560C37B400 for ; Tue, 2 Jul 2002 06:04:00 -0700 (PDT) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FF1443E0A for ; Tue, 2 Jul 2002 06:03:59 -0700 (PDT) (envelope-from bmilekic@angelica.unixdaemons.com) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.4/8.12.1) with ESMTP id g62D3s7g078913; Tue, 2 Jul 2002 09:03:55 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host bmilekic@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.4/8.12.1/Submit) id g62D3s6T078912; Tue, 2 Jul 2002 09:03:54 -0400 (EDT) (envelope-from bmilekic) Date: Tue, 2 Jul 2002 09:03:54 -0400 From: Bosko Milekic To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: Re: Mbuf allocator performance (was Should we keep a cache of mbuf+cluster ready for use ?) Message-ID: <20020702090354.A78632@unixdaemons.com> References: <20020702001050.B2250@iguana.icir.org> <20020702080423.A69693@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020702080423.A69693@unixdaemons.com>; from bmilekic@unixdaemons.com on Tue, Jul 02, 2002 at 08:04:23AM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jul 02, 2002 at 08:04:23AM -0400, Bosko Milekic wrote: > > There are several problems with your "simple" code that make it simpler > than what's in -CURRENT and in -STABLE and therefore yield [obviously] > seemingly better times. > > 1) sleeping in the case of a system exhausted of mbufs and clusters is > now broken because code that frees to this "combined" list will not > generate wake ups; even if you build this functionality in, you would > have to code the wakeup for a "special" case where one obtains both a > cluster and an mbuf; it'll get complicated. > > 2) no per-CPU caches, you bring contention (in -CURRENT) from per-CPU > back to global, which you probably don't care about now, but which will > matter when Giant goes completely. > > 3) you violate write/read producer/consumer model. In -CURRENT, we try > to not have the code doing the freeing write to any part of the mbuf, > thus hopefully avoiding cache invalidation from occuring during a free > that happens from a thread that doesn't usually write to the mbuf at > all. Forgot, also, in -CURRENT: 4) breaks framework in mb_alloc that groups pages of mbufs and clusters together allowing them to be freed in the future, if/when we decide to implement lazy freeing; it would do the same thing if we mvoed mbuf allocations to UMA, because grouping together mbufs and clusters on a separate list will violate that scheme. > I think that because of (1) and (2), especially, and because the kernel > in -CURRENT is the way it is right now, you're getting better > performance numbers. Try exhausting the system and seeing how far you > get. I suspect you'll eventually just hang (because you'll allocate a > bunch of stuff violating the real interface and then won't be able to > wakeup and Do The Right Thing). > > While, as I said before, I agree that we should have an interface that > allocates both an mbuf and a cluster, I don't think that this is the > right approach. I believe that the correct approach would be to couple > the mbuf and cluster allocation under a single per-CPU lock/unlock > operation, which isn't too difficult to do. > > On Tue, Jul 02, 2002 at 12:10:50AM -0700, Luigi Rizzo wrote: > > [Bcc to -current as relevant there] > > > > As a followup to my question below, i did some simple experiment > > on a -current box acting as a router, using two "em" cards and > > DEVICE_POLLING (just for stability). > > > > The whole of the code is basically below -- the receiving > > side tries to grab the mbuf+cluster from the free pool first, > > and falls back to the standard method on failure; the sending > > side tries to attach the freed buffer to the free pool > > if it is the case. > > > > There is a simplification here with respect to what could > > go into an m_freem()/mgethdr_cluster() pair because the driver > > is already holding a lock, on Giant in this case, so you do not need > > further locking. Still, to come to the data points: > > > > CURRENT STABLE (*) > > > > fastfwd=1, pool_max=0 276kpps 365 kpps > > fastfwd=1, pool_max=50 355kpps 383 kpps > > > > fastfwd=0, pool_max=0 195 pps 142 kpps > > fastfwd=0, pool_max=50 227 kpps 146 kpps > > > > (*) This version of STABLE that I am using for comparison has some > > proprietary optimizations which make it a bit faster than normal. > > However it still uses the old ipfw code, which is invoked when > > fastfwd=0, and is significantly slower than the new one. > > > > Now this really seems to call for adding this interface into the > > mbuf subsystem. I believe we have to find a name for the allocator > > (the deallocator might well go into m_freem(), depending on how we > > implement the locking) and whether it makes sense to lock > > mgethdr_cluster() under per-cpu locks or under Giant, or even let > > the caller make sure that it holds the proper lock before trying > > to invoke the procedure (as i expect the "producers" or "consumers" > > of these pairs to be located in the network stack, chances are that > > they already hold a lock on Giant). > > > > > > cheers > > luigi > > > > > > The code: > > > > struct mbuf *em_pool; > > > > static int em_pool_max = 50; > > SYSCTL_INT(_hw, OID_AUTO, em_pool_max, CTLFLAG_RW, > > &em_pool_max,0,"max size of mbuf pool"); > > static int em_pool_now; > > SYSCTL_INT(_hw, OID_AUTO, em_pool_now, CTLFLAG_RD, > > &em_pool_now,0,"Current size of mbuf pool"); > > > > ... in em_get_buf() .. > > > > if (em_pool) { > > mp = em_pool; > > em_pool = mp->m_nextpkt; > > em_pool_now--; > > goto have_it; > > } > > > > ... in em_clean_transmit_interrupts() ... > > if ((m = tx_buffer->m_head)) { > > if (em_pool_now < em_pool_max && > > m->m_next == NULL && > > m->m_flags & M_EXT && > > M_WRITABLE(m) ) { > > m->m_nextpkt = em_pool; > > em_pool = m; > > em_pool_now++; > > } else > > m_freem(m); > > tx_buffer->m_head = NULL; > > } > > Regards, > -- > Bosko Milekic > bmilekic@unixdaemons.com > bmilekic@FreeBSD.org > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 2 6:48:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3164037B400 for ; Tue, 2 Jul 2002 06:48:12 -0700 (PDT) Received: from kirk.rvdp.org (node147c0.a2000.nl [24.132.71.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F94543E0A for ; Tue, 2 Jul 2002 06:48:11 -0700 (PDT) (envelope-from rvdp@kirk.rvdp.org) Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id g62Dm8K21416 for freebsd-net@FreeBSD.ORG; Tue, 2 Jul 2002 15:48:08 +0200 (CEST) Date: Tue, 2 Jul 2002 15:48:08 +0200 From: Ronald van der Pol To: freebsd-net@FreeBSD.ORG Subject: status of conf/3517?; ipf(8) does not work for IPv6 Message-ID: <20020702134808.GA18209@rvdp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Their has been some discussion about conf/3517 which is about ipf(8) filtering for IPv6. I see -current has this in /etc/rc.d/ipfilter: ipfilter_start() { echo "Enabling ipfilter." case `${CMD_OSTYPE}` in FreeBSD) ${ipfilter_program:-/sbin/ipf} -Fa -f \ "${ipfilter_rules}" ${ipfilter_flags} ;; NetBSD) /sbin/ipf -E -Fa if [ -f /etc/ipf.conf ]; then /sbin/ipf -f /etc/ipf.conf fi if [ -f /etc/ipf6.conf ]; then /sbin/ipf -6 -f /etc/ipf6.conf fi ;; esac } Can FreeBSD do the same as NetBSD? There is another problem with the FreeBSD code. The ${ipfilter_flags} won't be executed at the end of the command. It seems that it needs to be before the -f flag: # ipf -6 -Fa -f /tmp/ipf.rules -v # ipf -6 -Fa -v -f /tmp/ipf.rules [pass in from any to 2001:abcd::/128] pass in from any to 2001:abcd::/128 # rvdp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 2 7:57: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3348237B400 for ; Tue, 2 Jul 2002 07:57:01 -0700 (PDT) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1FBC43E2F for ; Tue, 2 Jul 2002 07:57:00 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.11.6/8.11.6) id g62Eurm01747; Tue, 2 Jul 2002 08:56:53 -0600 (MDT) (envelope-from rousskov) Date: Tue, 2 Jul 2002 08:56:53 -0600 (MDT) From: Alex Rousskov To: John Angelmo Cc: net@FreeBSD.ORG Subject: Re: increasing throughput In-Reply-To: <3D21A17C.7060607@veidit.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 2 Jul 2002, John Angelmo wrote: > I was thinking of cunstructing a small routerbox in my sparetime. > Now since FreeBSD is my choise of OS i was thinking of a small box > silent box. > > So how can I combine speed, size, silence and price? > > I was thinking of vias small buget systems (via Eden) and to that > an extra intel pro 10/100 NIC You may also consider Soekris boxes, especially if you need a fan-less configuration. People use them for routers and firewalls. Some OpenBSD and FreeBSD documentation and software is available. You can probably find some performance measurements as well or ask on Soekris mailing list: http://www.soekris.com/ I am not associated with Soekris; we are just happy customers. Alex. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 2 8:29:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B04837B400 for ; Tue, 2 Jul 2002 08:29:13 -0700 (PDT) Received: from mail1.home.nl (mail1.home.nl [213.51.129.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D4A843E13 for ; Tue, 2 Jul 2002 08:29:12 -0700 (PDT) (envelope-from nascar24@home.nl) Received: from winxp ([217.120.146.224]) by mail1.home.nl (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20020702152910.KUTP342.mail1.home.nl@winxp> for ; Tue, 2 Jul 2002 17:29:10 +0200 Message-ID: <01c001c221dd$38127d20$0200a8c0@winxp> From: "nascar24" To: Subject: DHCP lease renewal Date: Tue, 2 Jul 2002 17:29:08 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BD_01C221ED.F91369C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_01BD_01C221ED.F91369C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hallo, My FreeBSD 4.5-RELEASE machine is connected to the internet via a cable = connection. And when booting (or running dhclient) I get an IP address. = But when I have an IP address and my ISP wants to give me a new IP = address I doesn't go the way it should. Because I don't get the new IP = address, my machine continues to use the 'old' IP address. And when that = happens I get an angry phone call from my ISP, and they shut me from = internet for a day. So, how can I configure (dhclient.conf I guess) my machine so that it = accepts this new IP address. I thought I would configure my machine so = that it renews its lease every 10 hours. But I have read the man for = dhclient.conf, dhcp-options and dhclient but I still am puzzled. Gr. Marcel. ------=_NextPart_000_01BD_01C221ED.F91369C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hallo,
 
My FreeBSD 4.5-RELEASE = machine is=20 connected to the internet via a cable connection. And when booting (or = running=20 dhclient) I get an IP address. But when I have an IP address and my ISP = wants to=20 give me a new IP address I doesn't go the way it should. Because I don't = get the=20 new IP address, my machine continues to use the 'old' IP address. And = when that=20 happens I get an angry phone call from my ISP, and they shut me from = internet=20 for a day.
 
So, how can I configure = (dhclient.conf I guess) my machine so that it accepts this new IP = address. I=20 thought I would configure my machine so that it renews its=20 lease every 10 hours. But I have read the man for dhclient.conf,=20 dhcp-options and dhclient but I still am puzzled.
 
Gr.
 
Marcel.
 
------=_NextPart_000_01BD_01C221ED.F91369C0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 2 8:56:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 01D5237B400 for ; Tue, 2 Jul 2002 08:56:43 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E73B43E13 for ; Tue, 2 Jul 2002 08:56:42 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g62Fuef07721; Tue, 2 Jul 2002 08:56:40 -0700 (PDT) (envelope-from rizzo) Date: Tue, 2 Jul 2002 08:56:40 -0700 From: Luigi Rizzo To: Bosko Milekic Cc: net@FreeBSD.ORG Subject: Re: Mbuf allocator performance (was Should we keep a cache of mbuf+cluster ready for use ?) Message-ID: <20020702085640.B5854@iguana.icir.org> References: <20020702001050.B2250@iguana.icir.org> <20020702080423.A69693@unixdaemons.com> <20020702090354.A78632@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020702090354.A78632@unixdaemons.com>; from bmilekic@unixdaemons.com on Tue, Jul 02, 2002 at 09:03:54AM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, you can read the numbers I posted as you like, but in the non-SMP case performance is not "seemingly" better, it IS better. Before people think differently: the code i posted is _perfectly safe_ to use under the assumption that I used -- i.e. that you hold Giant when manipulating the free list -- on both non-SMP (where i tested it, and where it does improve performancw) and SMP systems (where I have no idea about performance, but i might have some numbers by tomorrow), under the assumption that I used -- i.e. that you hold Giant when manipulating the free list. The above assumption holds in the device drivers i patched, and also (at the time of this writing, and I suspect for quite a bit, although I and hopefully others are working on this) in all the network stack. And of course you can #ifdef the code out for the SMP case if you don't trust it so you won't pessimize the SMP case. Also: I am not violating _any_ interface. I am just holding apart a small set of buffers for future use, which is exactly the same thing that each and every network device driver in FreeBSD does when it links them in the receive ring -- no guarantee when/if they will be freed, certainly none of them is freed even if the system runs out of mbufs (unless the network interface is brought down, which i doubt it happens). This said, a detailed answer to your points: #1 I think your comment on the sleepers and mbuf exhaustion is not correct. I am only talking of holding apart a small set of buffers+clusters, in the order of ~50 blocks, and you can restrict the consumers of the free pool to those who do not want to sleep, so there is not need to special-case the code for the sleepers. Or, if you really want to special case it, the first sleeper which finds the free pool empty and needs to go to sleep will reset max_pool_size to 0 forcing the same behaviour we have now with correct handling of wakeup and such. #2 given that all i am asking for is defining an interface for this type of optimization, when the time comes that Giant goes, and assuming I am not retired yet, it will still change nothing for the non-SMP case, and for the SMP case we can run our performance tests and if it proves to be useful we can put in whatever is necessary. #3 easy to fix (assuming this is really a problem) -- just have the free pool organized as a list of pointers to the mbufs, rather than using the m_nextpkt field as the link field. Because the free list is short and fixed size you can even use an array to hold it. #4 same answer of #2: if/when... we can easily fix things in just one place. Until then, we are just pessimizing things for no good reason. In terms of API, since we both agree that we need one (and we do need one, otherwise driver writers will just go ahead and do their own, replicating work in each driver, as I am sure I^hthey will start doing now), may I suggest that we export two-- one where the caller is assumed to already hold a lock on the CPU it is running on, and one which also does the necessary locking upfront and calls the latter afterwards ? This way the former will be usable right now and efficiently from all contexts which run under Giant, and easy to upgrade when/if we need it. And, I am sorry to say... you raise some valid points, but without performance numbers to justify them, it is hard to tell how relevant they are in practice. I have made too many mistakes of this kind myself to believe my intuition. cheers luigi On Tue, Jul 02, 2002 at 09:03:54AM -0400, Bosko Milekic wrote: > > There are several problems with your "simple" code that make it simpler > > than what's in -CURRENT and in -STABLE and therefore yield [obviously] > > seemingly better times. > > > > 1) sleeping in the case of a system exhausted of mbufs and clusters is > > now broken because code that frees to this "combined" list will not > > generate wake ups; even if you build this functionality in, you would > > have to code the wakeup for a "special" case where one obtains both a > > cluster and an mbuf; it'll get complicated. > > > > 2) no per-CPU caches, you bring contention (in -CURRENT) from per-CPU > > back to global, which you probably don't care about now, but which will > > matter when Giant goes completely. > > > > 3) you violate write/read producer/consumer model. In -CURRENT, we try > > to not have the code doing the freeing write to any part of the mbuf, > > thus hopefully avoiding cache invalidation from occuring during a free > > that happens from a thread that doesn't usually write to the mbuf at > > all. > > Forgot, also, in -CURRENT: > > 4) breaks framework in mb_alloc that groups pages of mbufs and > clusters together allowing them to be freed in the future, if/when we > decide to implement lazy freeing; it would do the same thing if we > mvoed mbuf allocations to UMA, because grouping together mbufs and > clusters on a separate list will violate that scheme. > > > I think that because of (1) and (2), especially, and because the kernel > > in -CURRENT is the way it is right now, you're getting better > > performance numbers. Try exhausting the system and seeing how far you > > get. I suspect you'll eventually just hang (because you'll allocate a > > bunch of stuff violating the real interface and then won't be able to > > wakeup and Do The Right Thing). > > > > While, as I said before, I agree that we should have an interface that > > allocates both an mbuf and a cluster, I don't think that this is the > > right approach. I believe that the correct approach would be to couple > > the mbuf and cluster allocation under a single per-CPU lock/unlock > > operation, which isn't too difficult to do. > 1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 2 9:11:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65B4937B400 for ; Tue, 2 Jul 2002 09:11:45 -0700 (PDT) Received: from kali.avantgo.com (shadow.avantgo.com [64.157.226.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28D9943E0A for ; Tue, 2 Jul 2002 09:11:45 -0700 (PDT) (envelope-from scott@avantgo.com) Received: from river.avantgo.com ([10.11.30.114]) by kali.avantgo.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 2 Jul 2002 09:11:44 -0700 Date: Tue, 2 Jul 2002 09:11:43 -0700 (PDT) From: Scott Hess To: John Angelmo Cc: net@freebsd.org Subject: Re: increasing throughput In-Reply-To: <3D21A17C.7060607@veidit.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 02 Jul 2002 16:11:44.0176 (UTC) FILETIME=[28923B00:01C221E3] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 2 Jul 2002, John Angelmo wrote: > I was thinking of cunstructing a small routerbox in my sparetime. Now > since FreeBSD is my choise of OS i was thinking of a small box silent > box. > > So how can I combine speed, size, silence and price? I'm very interested in this type of product (meaning "Really small box that's essentially a complete PC, without having to build an enclosure"). Here's a unit which I'm looking at (but, unfortunately, have yet to receive info on): http://www.advantech.com/products/Model_Detail.asp?model_id=1-8089T&bu= In case that doesn't work, select Network Computing/Network Appliances from the products popup, then Firewall Platforms. Any case, FWA-240 has a Celeron, 3 10/100 ethernet ports, a serial port, a DIMM slot, and a compact flash slot. You can also apparently fit a 2.5" drive in it. At 9"x7"x1.5", it's a bit bigger than I'd like to see, but still pretty compact. Later, scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 2 14: 5:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5083337B409 for ; Tue, 2 Jul 2002 14:05:08 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 541B9449D3 for ; Tue, 2 Jul 2002 12:30:02 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id MAA05479; Tue, 2 Jul 2002 12:15:17 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g62JEiG99589; Tue, 2 Jul 2002 12:14:44 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200207021914.g62JEiG99589@arch20m.dellroad.org> Subject: Re: mpd netgraph pptp server In-Reply-To: <200207011022.13398.Peter.Blok@inter.NL.net> "from Peter J. Blok at Jul 1, 2002 10:22:13 am" To: "Peter J. Blok" Date: Tue, 2 Jul 2002 12:14:44 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Peter J. Blok writes: > I have a gateway/firewall which is the spider in the web for different IP > segments. From two segments 192.168.2.0/24 and 192.168.10.0/24 I am trying to > setup PPTP tunnels. I have two different pptp sections (pptp1 and pptp2) in > both mpd.conf and mpd.links with unique names. Each pptp section has its own > "pptp self" listen address. > > The problem is that the mpd daemon only listens on the first pptp (pptp1) > section and doesn't listen on the 2nd (pptp2). When I load pptp2 first before > pptp1 it is the other way around. I am using sockstat -l to confirm where mpd > is listening on? Mpd only supports listening on one IP address for PPTP connections. Can you try changing both IP addresses to 0.0.0.0? -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 2 14: 6:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 157E437B6DC for ; Tue, 2 Jul 2002 14:05:59 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id A117544959 for ; Tue, 2 Jul 2002 12:15:02 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id MAA05416; Tue, 2 Jul 2002 12:03:20 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g62J2lf99571; Tue, 2 Jul 2002 12:02:47 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200207021902.g62J2lf99571@arch20m.dellroad.org> Subject: Re: Problem related to MPD In-Reply-To: <20020702103449.GA88663@daemon.overload.org> "from Jorgen Maas at Jul 2, 2002 12:34:49 pm" To: Jorgen Maas Date: Tue, 2 Jul 2002 12:02:47 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Jorgen Maas writes: > I've got an annoying problem here with MPD (3.8). > I use MPD to setup a PPTP session to my adsl modem, but after (approx) > 24 hours of being online my Internet connection gets slower and slower. > When I try to do a traceroute or a ping I get some warning: out of buffers > Then I restart MPD by issuing a mpd -bk and everything's fine again (for a while) A couple of other people have reported this problem as well. It's pretty mysterious and I've pretty much run out of ideas. It seems to affect people using ADSL modems for some reason. Next time it happens, email me the result of running these commands... $ ngctl msg ng0:inet.ppp getmpstate $ ngctl msg ng0:inet.ppp getlinkstats 0 $ ngctl msg ng0:inet.ppp.link0 getstats Also: can you email me the mpd log trace from when it initially connects to when the problem occurs? Thanks, -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 2 14:13:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4497537C208 for ; Tue, 2 Jul 2002 14:11:32 -0700 (PDT) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6250944395 for ; Tue, 2 Jul 2002 10:44:13 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g62Hkr518079; Tue, 2 Jul 2002 13:46:53 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Tue, 2 Jul 2002 13:46:53 -0400 From: Bosko Milekic To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: Re: Mbuf allocator performance (was Should we keep a cache of mbuf+cluster ready for use ?) Message-ID: <20020702134653.A17641@unixdaemons.com> References: <20020702001050.B2250@iguana.icir.org> <20020702080423.A69693@unixdaemons.com> <20020702090354.A78632@unixdaemons.com> <20020702085640.B5854@iguana.icir.org> <20020702130135.A17370@unixdaemons.com> <20020702101222.C7966@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020702101222.C7966@iguana.icir.org>; from rizzo@icir.org on Tue, Jul 02, 2002 at 10:12:22AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jul 02, 2002 at 10:12:22AM -0700, Luigi Rizzo wrote: > On Tue, Jul 02, 2002 at 01:01:35PM -0400, Bosko Milekic wrote: > ... > > The reason I said "seemingly" is because of the fact that I don't > > think that it is your "grouping" of both clusters and mbufs that > > specifically causes the perf. increase to the extent you showed with > > your tests. What you're doing in the code you posted is also avoiding > > could be, i don't know... but this is exactly why we both agree > that we better provide an interface so that we can work out in > parallel improvements in the driver and improvements in the mbuf > code. > > > 1) Remove the malloc() for external ref. count allocations; instead, > > store the ref. count at the end of the cluster like I did when I took > > this seems to violate one of your points about cache pollution! > but i am totally neutral on this one. The slot that contains the reference count line will be invalidated in either case so this is something that cannot be avoided in both cases (the malloc() case is doubly-worse, even), so if there's no way to avoid the invalidation (it's a per-cluster reference count after all), there's not much I can do about it. > > 2) Introduce an interface that will allocate and free: > > (i) an mbuf with a cluster attached to it; > > (ii) an M_PKTHDR mbuf with a cluster attached to it; > > However, this interface would wrap the appropriate alloc/free > > routines, although it would take care to not drop the allocation > > lock between the allocations. I don't suspect this to be too > > difficult to do. > > fine with me. Ok, so we agree on the interface and you've agreed to compromise on the solution. Now I just have to deliver. :-) I'll send you a patch by the end of the week. I've decided to haul in one of my -CURRENT test boxes to work and get some work done here, hopefully. > > It is not safe if you use it too often. The allocator was designed to > > allocate, it HAS caches, it doesn't need for everyone under the Sun to > > start keeping their own caches on top of that. > > which is what happens when they realise they can do things faster :) This is really bad philosophy. It is my understanding that to Do The Right thing, we ought to make certain compromises in design. We need to allow for certain functionality to exist and we cannot do that with per-driver hacked-up "solutions." Sure, I can hack up a small little per-softc list from which I may even be able to do allocations from WITHOUT a lock, but that'll introduce a whole new level of complexity (think about mbufs getting misplaced, etc.) With huge SMP-related changes, we cannot afford anymore of these spaghetti-like changes. > > Here's what happens: > > > > Consumers A and B each keep their own "pools" of mbufs+clusters. > > ... > > look, this is exactly what happens with network interfaces. If > they fail to allocate a new mbuf, they keep recycling > the one they have from the receive queue instead of freeing it. Yes, but that's because they _need_ an mbuf, they can't get one, so they re-use one. If you build a local pool in which you store UNUSED mbufs, with no real idea of when they'll be used - only with the assumption/hope that you'll use them "soon" - and if you do this in several different places in the kernel, you are bound to hit brokeness under heavy load, when you need to block from other locations to get your network buffers and cannot do that because someone else is "assuming" they'll need a bunch "sometime soon." This is why we have per-CPU caches and a global cache. The per-CPU caches load themselves accordingly, and they'll give you what you're looking for when you need it, from a cache. Sure, the caches are a tad bit more expensive to twiddle, but this is the compromise we make in order to ensure that the system knows about our caches and is able to cope even under heavy load. > cheers > luigi -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 2 14:13:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D9B237C43E for ; Tue, 2 Jul 2002 14:12:32 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with SMTP id 24132444BC for ; Tue, 2 Jul 2002 11:03:31 -0700 (PDT) (envelope-from oppermann@pipeline.ch) Received: (qmail 74926 invoked from network); 2 Jul 2002 18:02:31 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 2 Jul 2002 18:02:31 -0000 Message-ID: <3D21EAA0.B6198D7D@pipeline.ch> Date: Tue, 02 Jul 2002 20:02:08 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Scott Hess Cc: John Angelmo , net@freebsd.org Subject: Re: increasing throughput References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Scott Hess wrote: > > On Tue, 2 Jul 2002, John Angelmo wrote: > > I was thinking of cunstructing a small routerbox in my sparetime. Now > > since FreeBSD is my choise of OS i was thinking of a small box silent > > box. > > > > So how can I combine speed, size, silence and price? > > I'm very interested in this type of product (meaning "Really small box > that's essentially a complete PC, without having to build an enclosure"). > Here's a unit which I'm looking at (but, unfortunately, have yet to > receive info on): > > http://www.advantech.com/products/Model_Detail.asp?model_id=1-8089T&bu= > > In case that doesn't work, select Network Computing/Network Appliances > from the products popup, then Firewall Platforms. > > Any case, FWA-240 has a Celeron, 3 10/100 ethernet ports, a serial port, a > DIMM slot, and a compact flash slot. You can also apparently fit a 2.5" > drive in it. At 9"x7"x1.5", it's a bit bigger than I'd like to see, but > still pretty compact. Any indication of prices for this baby? -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 2 14:14:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02B3637C558 for ; Tue, 2 Jul 2002 14:12:57 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E74F449D4 for ; Tue, 2 Jul 2002 12:30:05 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id MAA05493; Tue, 2 Jul 2002 12:23:19 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g62JMkd99644; Tue, 2 Jul 2002 12:22:46 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200207021922.g62JMkd99644@arch20m.dellroad.org> Subject: Re: problems with mpd as a pptp server In-Reply-To: <3D1FD641.4050903@brainlink.com> "from Anthony Volodkin at Jul 1, 2002 00:10:41 am" To: Anthony Volodkin Date: Tue, 2 Jul 2002 12:22:46 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Anthony Volodkin writes: > - Now that perfectly works, (proxy-arp too, is very impressive) I am > trying to figure out how to forward broadcast packets from ng0 to fxp0 > and vice-versa. Something tells me since this is an interface created > by netgraph, it should be possible. I tried the ether.bridge in > /usr/share/examples/netgraph/ but I got the same error as I did with > tun0: interface ng0 not found. I suppose this is reasonable and intended. Broadcasts only propagate to the local (broadcast) link, and are not routed (in particular, they are not routed across a PPP point-to-point link). So what you want to do is not "normal" for IP. I belive there should be a sysctl however that enables forwarding of broadcast packets received on a broadcast link over any point-to-point links that have a remote IP address matching the broadcast link's subnet (e.g., proxy-ARP'd remote clients). This would be "gross" but would also probably solve whatever problem you're trying to address. BTW, if you are trying to get Windows browsing to work, a better answer is to set up a WINS server (e.g., Samba or NT) and let your PPTP clients know about it via the "set ipcp nbns ..." command. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 2 14:15:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37C0C37C1B5 for ; Tue, 2 Jul 2002 14:13:13 -0700 (PDT) Received: from smtp01.wxs.nl (smtp01.wxs.nl [195.121.6.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF1BB44CB0 for ; Tue, 2 Jul 2002 13:26:44 -0700 (PDT) (envelope-from Peter.Blok@inter.NL.net) Received: from bsdpc ([80.60.248.65]) by smtp01.wxs.nl (Netscape Messaging Server 4.15) with ESMTP id GYN24J02.0JV; Tue, 2 Jul 2002 22:26:43 +0200 Content-Type: text/plain; charset="iso-8859-1" From: "Peter J. Blok" To: Archie Cobbs Subject: Re: mpd netgraph pptp server Date: Tue, 2 Jul 2002 22:26:20 +0200 User-Agent: KMail/1.4.1 Cc: freebsd-net@FreeBSD.ORG References: <200207021914.g62JEiG99589@arch20m.dellroad.org> In-Reply-To: <200207021914.g62JEiG99589@arch20m.dellroad.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200207022226.20185.Peter.Blok@inter.NL.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tuesday 02 July 2002 21:14, Archie Cobbs wrote: > Peter J. Blok writes: > > I have a gateway/firewall which is the spider in the web for different IP > > segments. From two segments 192.168.2.0/24 and 192.168.10.0/24 I am > > trying to setup PPTP tunnels. I have two different pptp sections (pptp1 > > and pptp2) in both mpd.conf and mpd.links with unique names. Each pptp > > section has its own "pptp self" listen address. > > > > The problem is that the mpd daemon only listens on the first pptp (pptp1) > > section and doesn't listen on the 2nd (pptp2). When I load pptp2 first > > before pptp1 it is the other way around. I am using sockstat -l to > > confirm where mpd is listening on? > > Mpd only supports listening on one IP address for PPTP connections. > > Can you try changing both IP addresses to 0.0.0.0? Yes, I have done that after I looked at the source. The problem remained that it was picking the wrong link. Then I saw that based on the pptp peer address the best link is picked, which is what I use right now. Thx for the help anyway, Peter > > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 2 14:16:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E341537C5A8 for ; Tue, 2 Jul 2002 14:13:09 -0700 (PDT) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4F854413C for ; Tue, 2 Jul 2002 09:59:01 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g62H1Z117428; Tue, 2 Jul 2002 13:01:35 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Tue, 2 Jul 2002 13:01:35 -0400 From: Bosko Milekic To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: Re: Mbuf allocator performance (was Should we keep a cache of mbuf+cluster ready for use ?) Message-ID: <20020702130135.A17370@unixdaemons.com> References: <20020702001050.B2250@iguana.icir.org> <20020702080423.A69693@unixdaemons.com> <20020702090354.A78632@unixdaemons.com> <20020702085640.B5854@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020702085640.B5854@iguana.icir.org>; from rizzo@icir.org on Tue, Jul 02, 2002 at 08:56:40AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jul 02, 2002 at 08:56:40AM -0700, Luigi Rizzo wrote: > > Hi, > you can read the numbers I posted as you like, but in the non-SMP > case performance is not "seemingly" better, it IS better. The reason I said "seemingly" is because of the fact that I don't think that it is your "grouping" of both clusters and mbufs that specifically causes the perf. increase to the extent you showed with your tests. What you're doing in the code you posted is also avoiding an extra malloc() allocation of the cluster reference counter. Initially, the plan was to entirely remove the malloc() and store the ref. count at the end of the cluster. Briefly, I agree that the interface is useful (I already mentionned this, didn't I?) but I don't think that the approach of holding mbufs and clusters tied together on yet another list is the right one to make at this point. You mention that it's all OK under Giant, but I'd like to point out that making these sorts of "OK under Giant" assumptions when introducing new interfaces is taking us a step BACKWARDs, especially in light of the lockdown work that's being done. I propose the following compromise that I hope you will agree with: 1) Remove the malloc() for external ref. count allocations; instead, store the ref. count at the end of the cluster like I did when I took the original mb_alloc performance measurements. This should make allocations and frees visibly faster (I measured it, http://people.freebsd.org/~bmilekic/mb_alloc/results.html); 2) Introduce an interface that will allocate and free: (i) an mbuf with a cluster attached to it; (ii) an M_PKTHDR mbuf with a cluster attached to it; However, this interface would wrap the appropriate alloc/free routines, although it would take care to not drop the allocation lock between the allocations. I don't suspect this to be too difficult to do. I have a little bit of free time now while waiting for KSEIII to settle before taking up lightweight interrupts again, so I'm prepared to do both of these. > Before people think differently: > > the code i posted is _perfectly safe_ to use under the assumption > that I used -- i.e. that you hold Giant when manipulating the > free list -- on both non-SMP (where i tested it, and where it > does improve performancw) and SMP systems (where I have no idea > about performance, but i might have some numbers by tomorrow), > under the assumption that I used -- i.e. that you hold Giant > when manipulating the free list. It is not safe if you use it too often. The allocator was designed to allocate, it HAS caches, it doesn't need for everyone under the Sun to start keeping their own caches on top of that. > The above assumption holds in the device drivers i patched, and > also (at the time of this writing, and I suspect for quite a bit, > although I and hopefully others are working on this) in all the > network stack. > And of course you can #ifdef the code out for the SMP case if you > don't trust it so you won't pessimize the SMP case. > > Also: > > I am not violating _any_ interface. > I am just holding apart a small set of buffers for future use, > which is exactly the same thing that each and every network > device driver in FreeBSD does when it links them in the receive > ring -- no guarantee when/if they will be freed, certainly none > of them is freed even if the system runs out of mbufs (unless > the network interface is brought down, which i doubt it happens). > > This said, a detailed answer to your points: > > #1 I think your comment on the sleepers and mbuf exhaustion is > not correct. > I am only talking of holding apart a small set of buffers+clusters, > in the order of ~50 blocks, and you can restrict the consumers > of the free pool to those who do not want to sleep, so there > is not need to special-case the code for the sleepers. > Or, if you really want to special case it, the first sleeper > which finds the free pool empty and needs to go to sleep will > reset max_pool_size to 0 forcing the same behaviour we have now > with correct handling of wakeup and such. Here's what happens: Consumers A and B each keep their own "pools" of mbufs+clusters. Consumer C does not. At one point, A and B start allocating a little bit from their own pools. C comes in and allocates and eventually we run out of stuff to allocate so C blocks waiting for something to be freed. However, if A and B decide to free to their local pools instead of via the allocator, C will not get woken up. To make matters worse, here's a common scenario: A keeps his own pool. A allocates and allocates and allocates from local pool. C comes in and allocates "normally" through the allocator. C cannot find a cluster and is willing to block, so it does. A frees. No wakeup. A frees. No wakeup. A frees. No wakeup. ... maybe D frees and generates wakeup, maybe not. > #2 given that all i am asking for is defining an interface for this > type of optimization, when the time comes that Giant goes, and > assuming I am not retired yet, it will still change nothing for > the non-SMP case, and for the SMP case we can run our performance > tests and if it proves to be useful we can put in whatever > is necessary. I already told you that I think that the interface is OK; I don't think that keeping yet another freelist for this sort of thing is OK. The mbufs and clusters will be on their respective free lists anyway, there really isn't a point of keeping yet another list around, if you read the compromise above and assume that the malloc() will disappear from the common cluster allocation case. > #3 easy to fix (assuming this is really a problem) -- just have the > free pool organized as a list of pointers to the mbufs, rather than > using the m_nextpkt field as the link field. Because the free > list is short and fixed size you can even use an array to > hold it. This is what the existing cache lists do anyway. Again, there is no point of doing this AGAIN. > #4 same answer of #2: if/when... we can easily fix things in just > one place. Until then, we are just pessimizing things for no > good reason. > > In terms of API, since we both agree that we need one (and we do > need one, otherwise driver writers will just go ahead and do their > own, replicating work in each driver, as I am sure I^hthey will > start doing now), may I suggest that we export two-- one where the > caller is assumed to already hold a lock on the CPU it is running > on, and one which also does the necessary locking upfront and calls > the latter afterwards ? This way the former will be usable right > now and efficiently from all contexts which run under Giant, and > easy to upgrade when/if we need it. > > And, I am sorry to say... you raise some valid points, but without > performance numbers to justify them, it is hard to tell how relevant > they are in practice. > > I have made too many mistakes of this kind myself to believe my > intuition. > > cheers > luigi > > On Tue, Jul 02, 2002 at 09:03:54AM -0400, Bosko Milekic wrote: > > > > There are several problems with your "simple" code that make it simpler > > > than what's in -CURRENT and in -STABLE and therefore yield [obviously] > > > seemingly better times. > > > > > > 1) sleeping in the case of a system exhausted of mbufs and clusters is > > > now broken because code that frees to this "combined" list will not > > > generate wake ups; even if you build this functionality in, you would > > > have to code the wakeup for a "special" case where one obtains both a > > > cluster and an mbuf; it'll get complicated. > > > > > > 2) no per-CPU caches, you bring contention (in -CURRENT) from per-CPU > > > back to global, which you probably don't care about now, but which will > > > matter when Giant goes completely. > > > > > > 3) you violate write/read producer/consumer model. In -CURRENT, we try > > > to not have the code doing the freeing write to any part of the mbuf, > > > thus hopefully avoiding cache invalidation from occuring during a free > > > that happens from a thread that doesn't usually write to the mbuf at > > > all. > > > > Forgot, also, in -CURRENT: > > > > 4) breaks framework in mb_alloc that groups pages of mbufs and > > clusters together allowing them to be freed in the future, if/when we > > decide to implement lazy freeing; it would do the same thing if we > > mvoed mbuf allocations to UMA, because grouping together mbufs and > > clusters on a separate list will violate that scheme. > > > > > I think that because of (1) and (2), especially, and because the kernel > > > in -CURRENT is the way it is right now, you're getting better > > > performance numbers. Try exhausting the system and seeing how far you > > > get. I suspect you'll eventually just hang (because you'll allocate a > > > bunch of stuff violating the real interface and then won't be able to > > > wakeup and Do The Right Thing). > > > > > > While, as I said before, I agree that we should have an interface that > > > allocates both an mbuf and a cluster, I don't think that this is the > > > right approach. I believe that the correct approach would be to couple > > > the mbuf and cluster allocation under a single per-CPU lock/unlock > > > operation, which isn't too difficult to do. > > 1 > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 2 14:17:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 767EF37C614 for ; Tue, 2 Jul 2002 14:13:20 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id B009A44205 for ; Tue, 2 Jul 2002 10:12:24 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g62HCMq08288; Tue, 2 Jul 2002 10:12:22 -0700 (PDT) (envelope-from rizzo) Date: Tue, 2 Jul 2002 10:12:22 -0700 From: Luigi Rizzo To: Bosko Milekic Cc: net@FreeBSD.ORG Subject: Re: Mbuf allocator performance (was Should we keep a cache of mbuf+cluster ready for use ?) Message-ID: <20020702101222.C7966@iguana.icir.org> References: <20020702001050.B2250@iguana.icir.org> <20020702080423.A69693@unixdaemons.com> <20020702090354.A78632@unixdaemons.com> <20020702085640.B5854@iguana.icir.org> <20020702130135.A17370@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020702130135.A17370@unixdaemons.com>; from bmilekic@unixdaemons.com on Tue, Jul 02, 2002 at 01:01:35PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jul 02, 2002 at 01:01:35PM -0400, Bosko Milekic wrote: ... > The reason I said "seemingly" is because of the fact that I don't > think that it is your "grouping" of both clusters and mbufs that > specifically causes the perf. increase to the extent you showed with > your tests. What you're doing in the code you posted is also avoiding could be, i don't know... but this is exactly why we both agree that we better provide an interface so that we can work out in parallel improvements in the driver and improvements in the mbuf code. > 1) Remove the malloc() for external ref. count allocations; instead, > store the ref. count at the end of the cluster like I did when I took this seems to violate one of your points about cache pollution! but i am totally neutral on this one. > 2) Introduce an interface that will allocate and free: > (i) an mbuf with a cluster attached to it; > (ii) an M_PKTHDR mbuf with a cluster attached to it; > However, this interface would wrap the appropriate alloc/free > routines, although it would take care to not drop the allocation > lock between the allocations. I don't suspect this to be too > difficult to do. fine with me. > It is not safe if you use it too often. The allocator was designed to > allocate, it HAS caches, it doesn't need for everyone under the Sun to > start keeping their own caches on top of that. which is what happens when they realise they can do things faster :) > Here's what happens: > > Consumers A and B each keep their own "pools" of mbufs+clusters. > ... look, this is exactly what happens with network interfaces. If they fail to allocate a new mbuf, they keep recycling the one they have from the receive queue instead of freeing it. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 2 14:49:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB67D37B40F for ; Tue, 2 Jul 2002 14:49:51 -0700 (PDT) Received: from front1.chartermi.net (24.213.60.123.up.mi.chartermi.net [24.213.60.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2639A43E3B for ; Tue, 2 Jul 2002 14:49:50 -0700 (PDT) (envelope-from ircd@wrath.com) Received: from [24.247.40.60] (HELO danrc) by front1.chartermi.net (CommuniGate Pro SMTP 3.5.3) with SMTP id 733239 for freebsd-net@freebsd.org; Tue, 02 Jul 2002 17:49:49 -0400 Message-ID: <001b01c22212$6355fa90$0b01a8c0@fear.wrath.net> From: "Brian" To: References: Subject: Re: increasing throughput Date: Tue, 2 Jul 2002 17:49:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ----- Original Message ----- From: "Scott Hess" To: "John Angelmo" Cc: Sent: Tuesday, July 02, 2002 12:11 PM Subject: Re: increasing throughput > On Tue, 2 Jul 2002, John Angelmo wrote: > > I was thinking of cunstructing a small routerbox in my sparetime. Now > > since FreeBSD is my choise of OS i was thinking of a small box silent > > box. > > > > So how can I combine speed, size, silence and price? > > I'm very interested in this type of product (meaning "Really small box > that's essentially a complete PC, without having to build an enclosure"). > Here's a unit which I'm looking at (but, unfortunately, have yet to > receive info on): > > http://www.advantech.com/products/Model_Detail.asp?model_id=1-8089T&bu= > > In case that doesn't work, select Network Computing/Network Appliances > from the products popup, then Firewall Platforms. > > Any case, FWA-240 has a Celeron, 3 10/100 ethernet ports, a serial port, a > DIMM slot, and a compact flash slot. You can also apparently fit a 2.5" > drive in it. At 9"x7"x1.5", it's a bit bigger than I'd like to see, but > still pretty compact. Now that is pretty slick. If you find out how much it costs let us all know. I've always built my own cases because it has always either not been available or way too expensive to even think about buying. However, I don't expect the average information technology person to know what is in a machine shop let alone how to use any of the items found in one. If someone had the time they could capitalize on this market without much effort. > Later, > scott -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 2 19: 8: 1 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62EF837B400 for ; Tue, 2 Jul 2002 19:07:57 -0700 (PDT) Received: from mercury.i-pi.com (Mercury.i-pi.com [198.49.217.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EB1E43E46 for ; Tue, 2 Jul 2002 19:07:56 -0700 (PDT) (envelope-from ingham@i-pi.com) Received: from Clarke.i-pi.com (Clarke.i-pi.com [198.49.217.12]) by mercury.i-pi.com (8.12.4/8.12.3) with ESMTP id g6328lfO057411 for ; Tue, 2 Jul 2002 20:08:48 -0600 (MDT) (envelope-from ingham@i-pi.com) Subject: bridge loop without physical loop From: Kenneth Ingham To: net@freebsd.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 02 Jul 2002 20:07:54 -0600 Message-Id: <1025662074.50003.14.camel@Clarke.i-pi.com> Mime-Version: 1.0 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm having a problem where the bridging code seems to be doing weird things. To eliminate the possibility of a real loop, the second ethernet interface is connected to a hub with no machines on it. However, I am still seeing messages like: Jun 30 16:24:48 zprime /kernel: -- loop (0) 00.60.97.88.38.68 to ed1 from ep0 (active) Even weirder are these: Jun 30 15:31:46 zprime /kernel: arp: 00:60:97:8f:d5:92 is using my IP address 66.120.218.4! Jun 30 15:31:46 zprime /kernel: xx ouch, bdg_forward for local pkt Of special note is that 00:60:97:8f:d5:92 is the ethernet interface of the second ethernet card (the one hooked to the empty hub). The two ethernet cards are: ep0: <3Com Etherlink III 3C589> at port 0x240-0x24f irq 9 slot 1 on pccard1 ed1 at port 0x300-0x31f irq 9 flags 0x80000 slot 0 on pccard0 (this is a Linksys 10/100 card) Any suggestions about what is going on here? -- Kenneth Ingham ingham@i-pi.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 2 19:29:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C7FE37B400 for ; Tue, 2 Jul 2002 19:29:24 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1670243E3D for ; Tue, 2 Jul 2002 19:29:24 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g632TLC12417; Tue, 2 Jul 2002 19:29:21 -0700 (PDT) (envelope-from rizzo) Date: Tue, 2 Jul 2002 19:29:21 -0700 From: Luigi Rizzo To: Kenneth Ingham Cc: net@FreeBSD.ORG Subject: Re: bridge loop without physical loop Message-ID: <20020702192921.B12152@iguana.icir.org> References: <1025662074.50003.14.camel@Clarke.i-pi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1025662074.50003.14.camel@Clarke.i-pi.com>; from ingham@i-pi.com on Tue, Jul 02, 2002 at 08:07:54PM -0600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org bridging is incompatible with cards which hear their own transmissions (~IFF_SIMPLEX). I am not sure if the "ep" is one of this kind. if you do an 'ifconfig' and you do not see the 'SIMPLEX' flag set for the card, then you can suspect that. I should probably put code in the bridging code to make sure that these cards are never enabled to do bridging. cheers luigi On Tue, Jul 02, 2002 at 08:07:54PM -0600, Kenneth Ingham wrote: > I'm having a problem where the bridging code seems to be doing weird > things. To eliminate the possibility of a real loop, the second > ethernet interface is connected to a hub with no machines on it. > However, I am still seeing messages like: > > Jun 30 16:24:48 zprime /kernel: -- loop (0) 00.60.97.88.38.68 to ed1 > from ep0 (active) > > Even weirder are these: > > Jun 30 15:31:46 zprime /kernel: arp: 00:60:97:8f:d5:92 is using my IP > address 66.120.218.4! > Jun 30 15:31:46 zprime /kernel: xx ouch, bdg_forward for local pkt > > Of special note is that 00:60:97:8f:d5:92 is the ethernet interface of > the second ethernet card (the one hooked to the empty hub). > > The two ethernet cards are: > ep0: <3Com Etherlink III 3C589> at port 0x240-0x24f irq 9 slot 1 on > pccard1 > ed1 at port 0x300-0x31f irq 9 flags 0x80000 slot 0 on pccard0 > (this is a Linksys 10/100 card) > > Any suggestions about what is going on here? > > -- > Kenneth Ingham > ingham@i-pi.com > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 2 19:34:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8192537B405 for ; Tue, 2 Jul 2002 19:34:39 -0700 (PDT) Received: from patrocles.silby.com (d111.as6.nwbl0.wi.voyager.net [169.207.128.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67BE843E54 for ; Tue, 2 Jul 2002 19:34:37 -0700 (PDT) (envelope-from silby@silby.com) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.4/8.12.4) with ESMTP id g632bacv093085; Tue, 2 Jul 2002 21:37:36 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.4/8.12.4/Submit) with ESMTP id g632bXX9093082; Tue, 2 Jul 2002 21:37:35 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Tue, 2 Jul 2002 21:37:33 -0500 (CDT) From: Mike Silbersack To: Tom Pavel Cc: net@FreeBSD.ORG Subject: Re: questions about TCP RST validity In-Reply-To: <200207020836.g628aBR64517@scout.networkphysics.com> Message-ID: <20020702211901.O92440-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 2 Jul 2002, Tom Pavel wrote: > > >>>>> On Mon, 1 Jul 2002, Mike Silbersack writes: > > > > 09:05:36.961787 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111 > > 261 win 4380 (DF) > > > 09:05:38.973207 AA.80 > BB.61390: . 3568529946:3568531406(1460) ack 2597111 > > 261 win 4380 (DF) > > > > Is this a real trace? It looks highly irregular to me. I don't see why > > BB isn't RSTing each packet, and AA looks to be retransmitting way too > > quickly. > > Yes, this is a real trace. And it is not a single fluke BB host > either. If you look at enough web traces, you will eventually find > such examples (it is pretty rare, though). Other OSes I was able to > test show the same behavior as AA. I included my theories about the > cause for BB's behavior (stateful firewall or modem hangup), but I > really have no info about that. > > I'm not sure why you say the retrans are too quick. The 2 above are 1 > sec and 2 sec, respectively. The rest continue exponentially. Urk. I misread the timestamps, sorry. Yes, the spacing looks correct, AA looks ok to me now. I guess the bug in BB isn't all too surprising either, sending a RST after a FIN sounds like a rare case. I suppose that the client app abruptly terminating the connection could cause it. In either case, it's likely just an off by one due to lack of accounting for the FIN. > That sounds pretty reasonable. All of the traces I have noticed came > with an "early" FIN from the web client, so even 1 byte would have > been enough in those cases. One MSS sounds like a good compromise. > > > Tom Pavel Actually, I'm thinking that one byte is probably all we'd want to stretch it, unless you have evidence of situations where > 1 byte differences have been seen. I'd also like to know which OS / stateful firewall is exhibiting the problem. If it's something really rare, the workaround might not be worth the hassle. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 3 7:11:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BA6A37B400 for ; Wed, 3 Jul 2002 07:11:52 -0700 (PDT) Received: from ns.giranti.co.id (ns.giranti.co.id [202.95.136.78]) by mx1.FreeBSD.org (Postfix) with SMTP id 1E11E43E31 for ; Wed, 3 Jul 2002 07:11:45 -0700 (PDT) (envelope-from odhienx@giranti.co.id) Received: (qmail 325 invoked by uid 1008); 3 Jul 2002 14:07:31 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 3 Jul 2002 14:07:31 -0000 Date: Wed, 3 Jul 2002 21:07:31 +0700 (WIT) From: hantu To: freebsd-net@freebsd.org Subject: still digiboard pc/8i Message-ID: <20020703210440.M320-100000@ns.giranti.co.id> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org hi all here is my log on /var/log/mgetty.cuaD0x 07/03 21:45:43 D07 mgetty: experimental test release 1.1.28-Jan10 07/03 21:45:43 D07 check for lockfiles 07/03 21:45:43 D07 locking the line 07/03 21:45:43 D07 WARNING: DSR is off - modem turned off or bad cable? 07/03 21:45:43 D07 lowering DTR to reset Modem 07/03 21:45:44 D07 send: ATS0=0Q0&D3&C1[0d] 07/03 21:45:44 D07 waiting for ``OK'' 07/03 21:46:04 D07 timeout in chat script, waiting for `OK' 07/03 21:46:04 D07 init chat timed out, trying force-init-chat 07/03 21:46:04 D07 send: \d[10][03]\d\d\d+++\d\d\d[0d]\dATQ0V1H0[0d] 07/03 21:46:08 D07 waiting for ``OK'' when i want test the line using tip... the error messages still All ports busy thanks oo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 3 8:46:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5AC037B40B for ; Wed, 3 Jul 2002 08:46:34 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 5620843E42 for ; Wed, 3 Jul 2002 08:46:27 -0700 (PDT) (envelope-from andreas-moeller@gmx.net) Received: (qmail 25987 invoked by uid 0); 3 Jul 2002 15:45:52 -0000 Received: from p5084ac7d.dip.t-dialin.net (HELO gmx.net) (80.132.172.125) by mail.gmx.net (mp011-rz3) with SMTP; 3 Jul 2002 15:45:52 -0000 Message-ID: <3D231C18.8020408@gmx.net> Date: Wed, 03 Jul 2002 17:45:28 +0200 From: =?ISO-8859-1?Q?Andreas_M=F6ller?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020702 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: How to determine the address of a network interface? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, I am trying to write a small program in C that just outputs the IP address of an arbitrary network interface (like ifconfig, but only the address). The problem is, I don't know how I can determine the address and my programming experience is too limited in order to fully understand the ifconfig source code (I think ifconfig determines the address through the function in_status() in ifconfig.c, though I don't comprehend it). It would be nice if anybody could point out how I should proceed or where I can find more information. Thanks a lot in advance, Andreas PS: I apologize if this is the wrong list for my questions. Please also excuse any language mistakes since English is not my native language. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 3 9: 6:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8634837B400 for ; Wed, 3 Jul 2002 09:06:25 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 433BE43E09 for ; Wed, 3 Jul 2002 09:06:24 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g63G6KT52519; Wed, 3 Jul 2002 09:06:20 -0700 (PDT) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.4/8.12.4/Submit) id g63Fsuge013706; Wed, 3 Jul 2002 08:54:56 -0700 (PDT) Date: Wed, 3 Jul 2002 08:54:56 -0700 (PDT) Message-Id: <200207031554.g63Fsuge013706@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: lmckenna@lodgenet.com Subject: Re: bge problem under 4.6-stable In-Reply-To: <3EA88113DE92D211807300805FA7994209149EE8@chaplin.lodgenet.com> References: <3EA88113DE92D211807300805FA7994209149EE8@chaplin.lodgenet.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <3EA88113DE92D211807300805FA7994209149EE8@chaplin.lodgenet.com>, McKenna, Lee wrote: > I have two machines with new 3Com 3C996B-T adapters using the bge0 driver > and I am having a problem with nfs. I can mount the server from the client, > and I can cd into the mounted directory, but as soon as I do an 'ls' > command, the client appears to hang. Strange loooking packets occasionally > show up in tcpdump with what appears to be huge, invalid port numbers and > the packets appear to be fragments?. > > I can ftp to/from the server just fine. > > I tried changing ETHER_ALIGN to 0, but same results. Tried media 100baseTX > to force both cards to 100Mbps, same results. I removed the gigabit switch > and used a crossover cable between the 2 machines, same results. > > I removed the bge0 cards and put in good ol' reliable fxp0 cards using same > crossover cable and everything works fine. Thanks for reporting this. I had a moment to look into it last night, and I could easily reproduce the problem. Something is wrong with the hardware checksum offloading for transmitted IP fragments. If you do the NFS mount with read and write sizes of 1024 so that no fragmentation occurs, the problem goes away. I suspect that the default read/write sizes of 8K would work if you enabled jumbo frames by setting the MTU to 9000 on each end. (That's assuming your switch supports jumbo frames.) This quick hack to the bge driver (in -stable) also makes it work. It disables all support for HW checksums: Index: if_bge.c =================================================================== RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v retrieving revision 1.3.2.12 diff -u -r1.3.2.12 if_bge.c --- if_bge.c 30 Jun 2002 17:46:35 -0000 1.3.2.12 +++ if_bge.c 3 Jul 2002 15:40:58 -0000 @@ -1689,9 +1689,11 @@ ifp->if_init = bge_init; ifp->if_mtu = ETHERMTU; ifp->if_snd.ifq_maxlen = BGE_TX_RING_CNT - 1; +#if 0 ifp->if_hwassist = BGE_CSUM_FEATURES; ifp->if_capabilities = IFCAP_HWCSUM; ifp->if_capenable = ifp->if_capabilities; +#endif /* Save ASIC rev. */ You could probably get the same effect without modifying the driver by adding "-txcsum" to the ifconfig arguments, but I didn't think to try that last night. This fix can be refined either to fix checksum offloading of fragments or to disable the offloading for fragments without disabling it for other packets. I ran out of time last night, but I'll work on that Real Soon Now. Note, the bug may not be in the driver itself. I think the bge driver is the only one that even attempts to do checksum offloading for fragments. So the bug could easily be elsewhere in the system. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 3 10:11:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD12B37B400 for ; Wed, 3 Jul 2002 10:11:45 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4CE943E31 for ; Wed, 3 Jul 2002 10:11:45 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 71A38AE25A; Wed, 3 Jul 2002 10:11:45 -0700 (PDT) Date: Wed, 3 Jul 2002 10:11:45 -0700 From: Alfred Perlstein To: Andreas =?iso-8859-1?Q?M=F6ller?= Cc: freebsd-net@freebsd.org Subject: Re: How to determine the address of a network interface? Message-ID: <20020703171145.GD97638@elvis.mu.org> References: <3D231C18.8020408@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3D231C18.8020408@gmx.net> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Andreas Möller [020703 08:59] wrote: > Hello, > > I am trying to write a small program in C that just outputs the IP > address of an arbitrary network interface (like ifconfig, but only the > address). The problem is, I don't know how I can determine the address > and my programming experience is too limited in order to fully > understand the ifconfig source code (I think ifconfig determines the > address through the function in_status() in ifconfig.c, though I don't > comprehend it). > > It would be nice if anybody could point out how I should proceed or > where I can find more information. > > > Thanks a lot in advance, > > Andreas > > PS: I apologize if this is the wrong list for my questions. Please also > excuse any language mistakes since English is not my native language. Your english is fine and this is an ok list to ask technical network related questions. Ok, now that you're re-assured, check out the manpage for 'getifaddrs' that sounds like what you might need. The getifaddrs(3) function returns a list of all the network devices in the system. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 3 12: 2:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACD1C37B400 for ; Wed, 3 Jul 2002 12:02:51 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2321743E09 for ; Wed, 3 Jul 2002 12:02:47 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id PAA10252; Wed, 3 Jul 2002 15:02:46 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g63J2GX25814; Wed, 3 Jul 2002 15:02:16 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15651.19000.140836.582511@grasshopper.cs.duke.edu> Date: Wed, 3 Jul 2002 15:02:16 -0400 (EDT) To: John Polstra Cc: net@freebsd.org, lmckenna@lodgenet.com Subject: Re: bge problem under 4.6-stable In-Reply-To: <200207031554.g63Fsuge013706@vashon.polstra.com> References: <3EA88113DE92D211807300805FA7994209149EE8@chaplin.lodgenet.com> <200207031554.g63Fsuge013706@vashon.polstra.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org John Polstra writes: > Something is wrong with the hardware checksum offloading for <..> > +#if 0 > ifp->if_hwassist = BGE_CSUM_FEATURES; > ifp->if_capabilities = IFCAP_HWCSUM; > ifp->if_capenable = ifp->if_capabilities; > +#endif <...> > Note, the bug may not be in the driver itself. I think the bge driver > is the only one that even attempts to do checksum offloading for > fragments. So the bug could easily be elsewhere in the system. Why not try removing CSUM_IP_FRAG from BGE_CSUM_FEATURES? Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 3 12:10:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD69737B400 for ; Wed, 3 Jul 2002 12:10:28 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id F416143E31 for ; Wed, 3 Jul 2002 12:10:27 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g63JAPT53797; Wed, 3 Jul 2002 12:10:25 -0700 (PDT) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.4/8.12.4/Submit) id g63JAPZf000385; Wed, 3 Jul 2002 12:10:25 -0700 (PDT) (envelope-from jdp) Date: Wed, 3 Jul 2002 12:10:25 -0700 (PDT) Message-Id: <200207031910.g63JAPZf000385@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: gallatin@cs.duke.edu Subject: Re: bge problem under 4.6-stable In-Reply-To: <15651.19000.140836.582511@grasshopper.cs.duke.edu> References: <3EA88113DE92D211807300805FA7994209149EE8@chaplin.lodgenet.com> <200207031554.g63Fsuge013706@vashon.polstra.com> <15651.19000.140836.582511@grasshopper.cs.duke.edu> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <15651.19000.140836.582511@grasshopper.cs.duke.edu>, Andrew Gallatin wrote: > > John Polstra writes: > > Something is wrong with the hardware checksum offloading for > <..> > > > +#if 0 > > ifp->if_hwassist = BGE_CSUM_FEATURES; > > ifp->if_capabilities = IFCAP_HWCSUM; > > ifp->if_capenable = ifp->if_capabilities; > > +#endif > > <...> > > > Note, the bug may not be in the driver itself. I think the bge driver > > is the only one that even attempts to do checksum offloading for > > fragments. So the bug could easily be elsewhere in the system. > > Why not try removing CSUM_IP_FRAG from BGE_CSUM_FEATURES? I'm going to. I just had a few minutes last night to work on it, so I tried disabling all checksum offloading to see if the problem had anything to do with that at all. Then I ran out of time. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 3 14: 3:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2027C37B400 for ; Wed, 3 Jul 2002 14:03:13 -0700 (PDT) Received: from pan.ch.intel.com (chfdns01.ch.intel.com [143.182.246.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9393643E31 for ; Wed, 3 Jul 2002 14:03:12 -0700 (PDT) (envelope-from joydeepx.roy@intel.com) Received: from azsmsxvs043.ch.intel.com (azsmsxvs043.ch.intel.com [10.2.248.13]) by pan.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g63L3C315426 for ; Wed, 3 Jul 2002 21:03:12 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by azsmsxvs043.ch.intel.com (NAVGW 2.5.2.11) with SMTP id M2002070314031126752 for ; Wed, 03 Jul 2002 14:03:12 -0700 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 14:03:11 -0700 Message-ID: <288F9BF66CD9D5118DF400508B68C44601287A71@orsmsx113.jf.intel.com> From: "Roy, JoydeepX" To: "'freebsd-net@FreeBSD.ORG'" Subject: auth d84cfc5e subscribe freebsd-net joydeepx.roy@intel.com Date: Wed, 3 Jul 2002 14:03:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 3 16:30:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00E3D37B400 for ; Wed, 3 Jul 2002 16:30:47 -0700 (PDT) Received: from mercury.i-pi.com (Mercury.i-pi.com [198.49.217.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26E4443E31 for ; Wed, 3 Jul 2002 16:30:46 -0700 (PDT) (envelope-from ingham@i-pi.com) Received: from Clarke.i-pi.com (Clarke.i-pi.com [198.49.217.12]) by mercury.i-pi.com (8.12.4/8.12.3) with ESMTP id g63NVRfO008333; Wed, 3 Jul 2002 17:31:28 -0600 (MDT) (envelope-from ingham@i-pi.com) Subject: Re: bridge loop without physical loop From: Kenneth Ingham To: Luigi Rizzo Cc: net@FreeBSD.ORG In-Reply-To: <20020702192921.B12152@iguana.icir.org> References: <1025662074.50003.14.camel@Clarke.i-pi.com> <20020702192921.B12152@iguana.icir.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 03 Jul 2002 17:30:43 -0600 Message-Id: <1025739044.50003.28.camel@Clarke.i-pi.com> Mime-Version: 1.0 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 2002-07-02 at 20:29, Luigi Rizzo wrote: > bridging is incompatible with cards which hear their own > transmissions (~IFF_SIMPLEX). I am not sure if the "ep" is one of this kind. > if you do an 'ifconfig' and you do not see the 'SIMPLEX' flag > set for the card, then you can suspect that. Here are the ifconfig results: ed1: flags=8802 mtu 1500 ether 00:e0:98:87:c7:a7 media: Ethernet autoselect (10baseT/UTP) status: active ep0: flags=a843 mtu 1500 inet XX.XX.XX.XX netmask 0xfffffff8 broadcast XX.XX.XX.XX inet6 fe80::260:97ff:fe8f:d592%ep0 prefixlen 64 scopeid 0x5 atalk 65280.127 range 0-65534 phase 2 broadcast 0.255 inet XX.XX.XX.XX netmask 0xffffffff broadcast XX.XX.XX.XX ether 00:60:97:8f:d5:92 media: Ethernet 10baseT/UTP So both of these should work, right? -- Kenneth Ingham ingham@i-pi.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 3 22:15:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F15E137B400 for ; Wed, 3 Jul 2002 22:15:40 -0700 (PDT) Received: from utility.clubscholarship.com (utility.clubscholarship.com [198.78.70.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FB4F43E09 for ; Wed, 3 Jul 2002 22:15:40 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Received: from localhost (root@localhost) by utility.clubscholarship.com (8.11.6/8.11.6) with ESMTP id g645DZY48731 for ; Wed, 3 Jul 2002 22:13:35 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Date: Wed, 3 Jul 2002 22:13:35 -0700 (PDT) From: Patrick Thomas To: Subject: comments on linksys usb100m "key" adaptor ? Message-ID: <20020703221142.O79469-100000@utility.clubscholarship.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is very nifty: http://www.linksys.com/products/product.asp?grid=31&prid=402 It is a 10/100 USB ethernet adaptor, but as you can see it is simply a USB "key" - no cables or dongles. Has anyone gotten this to work under FreeBSD ? I would like to think it uses the same linksys USB adaptor that already works in FreeBSD ... Comments ? --pt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 3 23:32:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B2F837B400 for ; Wed, 3 Jul 2002 23:32:27 -0700 (PDT) Received: from spork.pantherdragon.org (spork.pantherdragon.org [206.29.168.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA52643E3B for ; Wed, 3 Jul 2002 23:32:26 -0700 (PDT) (envelope-from dmp@pantherdragon.org) Received: from spark.techno.pagans (spark.techno.pagans [4.61.202.145]) by spork.pantherdragon.org (Postfix) with ESMTP id C105A471DA; Wed, 3 Jul 2002 23:32:25 -0700 (PDT) Received: from pantherdragon.org (speck.techno.pagans [172.21.42.2]) by spark.techno.pagans (Postfix) with ESMTP id 637FDFEBE; Wed, 3 Jul 2002 23:32:23 -0700 (PDT) Message-ID: <3D23EBF7.4D668194@pantherdragon.org> Date: Wed, 03 Jul 2002 23:32:23 -0700 From: Darren Pilgrim X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrick Thomas Cc: freebsd-net@freebsd.org Subject: Re: comments on linksys usb100m "key" adaptor ? References: <20020703221142.O79469-100000@utility.clubscholarship.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Patrick Thomas wrote: > > This is very nifty: > > http://www.linksys.com/products/product.asp?grid=31&prid=402 > > It is a 10/100 USB ethernet adaptor, but as you can see it is simply a USB > "key" - no cables or dongles. > > Has anyone gotten this to work under FreeBSD ? I would like to think it > uses the same linksys USB adaptor that already works in FreeBSD ... > > Comments ? They break easily and can overstrain or break the USB port if the network cable gets pulled. Horror stories about 3com's "x-jack" design are apropos. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 3 23:35:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4977037B405 for ; Wed, 3 Jul 2002 23:35:01 -0700 (PDT) Received: from amur.ru (amur.ru [195.151.156.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F5EE43E31 for ; Wed, 3 Jul 2002 23:34:57 -0700 (PDT) (envelope-from dek@dt.amur.ru) Received: from anubis.my.domain (ns.dt.amur.ru [194.84.87.182]) by amur.ru (8.11.6/8.11.6) with ESMTP id g646Yru03602 for ; Thu, 4 Jul 2002 16:34:53 +1000 Received: from there (ws-0122-01.my.domain [192.168.0.110]) by anubis.my.domain (Postfix) with SMTP id 499A61544E for ; Thu, 4 Jul 2002 16:34:49 +1000 (YAKST) Content-Type: text/plain; charset="koi8-r" From: Dmitry Krasnov Organization: DT International To: freebsd-net@freebsd.org Subject: Problem with ifconfig+alias Date: Thu, 4 Jul 2002 16:35:00 +1000 X-Mailer: KMail [version 1.3] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020704063449.499A61544E@anubis.my.domain> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello! I have problem with aliases after upgrade to 4.6-STABLE. I can not assign aliases on any interface: # ifconfig cx0 cx0: flags=8051 mtu 1500 inet xxx.xx.xx.182 --> xxx.xx.xx.181 netmask 0xfffffffc # ifconfig cx0 alias xxx.xx.xx.179 netmask 0xffffffff xxx.xx.xx.181 ifconfig: ioctl(SIOCAIFADDR): File exists I tried ppp0 for the simple test and got same results: # ifconfig ppp0 ppp0: flags=8010 mtu 1500 # ifconfig ppp0 10.0.0.2 netmask 0xfffffff0 10.0.0.1 # ifconfig ppp0 alias 10.0.0.3 netmask 0xffffffff 10.0.0.1 ifconfig: ioctl(SIOCAIFADDR): File exists Before upgrade I've used 4.5-STABLE, cvsup'ed at 2002-02-15. If I boot with /kernel.old everything works fine: [...] # ifconfig cx0 cx0: flags=8051 mtu 1500 inet xxx.xx.xx.182 --> xxx.xx.xx.181 netmask 0xfffffffc inet xxx.xx.xx.179 --> xxx.xx.xx.181 netmask 0xffffffff Same with ppp0: [...] # ifconfig ppp0 ppp0: flags=8010 mtu 1500 inet 10.0.0.2 --> 10.0.0.1 netmask 0xfffffff0 inet 10.0.0.3 --> 10.0.0.1 netmask 0xffffffff What's wrong? Any suggestions? -- /Dmitry Krasnov, Systems Engineer, JV DT International E-mail: dek(at)dt.amur.ru, Mobile: +7 (4162) 359002 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 4 3:39:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E9EB37B400 for ; Thu, 4 Jul 2002 03:39:06 -0700 (PDT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A5C643E42 for ; Thu, 4 Jul 2002 03:39:04 -0700 (PDT) (envelope-from ikostov@otel.net) Received: from judicator.otel.net ([212.36.9.113]) by mail.otel.net with esmtp (Exim 3.36 #1) id 17Q40R-000GDd-00; Thu, 04 Jul 2002 13:38:35 +0300 Date: Thu, 4 Jul 2002 13:38:35 +0300 (EEST) From: Iasen Kostov To: Bosko Milekic Cc: Luigi Rizzo , Subject: Re: Mbuf allocator performance (was Should we keep a cache of mbuf+cluster ready for use ?) In-Reply-To: <20020702134653.A17641@unixdaemons.com> Message-ID: <20020704131637.L52213-100000@shadowhand.OTEL.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 2 Jul 2002, Bosko Milekic wrote: ... > > > Here's what happens: > > > > > > Consumers A and B each keep their own "pools" of mbufs+clusters. > > > ... > > > > look, this is exactly what happens with network interfaces. If > > they fail to allocate a new mbuf, they keep recycling > > the one they have from the receive queue instead of freeing it. > > Yes, but that's because they _need_ an mbuf, they can't get one, so > they re-use one. If you build a local pool in which you store UNUSED > mbufs, with no real idea of when they'll be used - only with the > assumption/hope that you'll use them "soon" - and if you do this in > several different places in the kernel, you are bound to hit brokeness > under heavy load, when you need to block from other locations to get > your network buffers and cannot do that because someone else is > "assuming" they'll need a bunch "sometime soon." But if it is tunable ? And if it can be tuned for specific task that the signle machine do ? As example you can set something like "keep_buffers" for parts of system that you need to work faster in your single case. It could be a kernel variable, #ifdef or both. > > This is why we have per-CPU caches and a global cache. The per-CPU > caches load themselves accordingly, and they'll give you what you're > looking for when you need it, from a cache. Sure, the caches are a > tad bit more expensive to twiddle, but this is the compromise we make > in order to ensure that the system knows about our caches and is able > to cope even under heavy load. > > > cheers > > luigi > > -- > Bosko Milekic > bmilekic@unixdaemons.com > bmilekic@FreeBSD.org > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 4 9:32: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BBEE37B400 for ; Thu, 4 Jul 2002 09:32:03 -0700 (PDT) Received: from proton.hexanet.fr (proton.hexanet.fr [81.23.32.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5564443E09 for ; Thu, 4 Jul 2002 09:32:02 -0700 (PDT) (envelope-from c.prevotaux@hexanet.fr) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.12.3/8.12.3) with SMTP id g64GVxCE086056 for ; Thu, 4 Jul 2002 18:31:59 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Thu, 4 Jul 2002 18:31:59 +0200 From: Christophe Prevotaux To: net@freebsd.org Subject: 'vr' watchdog timeout Message-Id: <20020704183159.3d42699a.c.prevotaux@hexanet.fr> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-portbld-freebsd4.4) X-NCC-RegID: fr.hexanet Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi As others I do have the 'vr' driver bug that will give the "watchdog timeout" message under interface heavy load I am using 4.6-STABLE , I am wondering if this has been fixed yet. It is very annoying since it can bring a system down by shutting down its network interface completely. -- -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 61 77 72 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 4 13:59:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E094037B400; Thu, 4 Jul 2002 13:59:39 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2B1243E09; Thu, 4 Jul 2002 13:59:35 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id QAA07652; Thu, 4 Jul 2002 16:59:32 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g64Kx2g27620; Thu, 4 Jul 2002 16:59:02 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15652.46870.463359.853754@grasshopper.cs.duke.edu> Date: Thu, 4 Jul 2002 16:59:02 -0400 (EDT) To: Bosko Milekic Cc: "Kenneth D. Merry" , current@FreeBSD.ORG, net@FreeBSD.ORG Subject: virtually contig jumbo mbufs (was Re: new zero copy sockets snapshot) In-Reply-To: <20020620134723.A22954@unixdaemons.com> References: <20020618223635.A98350@panzer.kdm.org> <20020619090046.A2063@panzer.kdm.org> <20020619120641.A18434@unixdaemons.com> <15633.17238.109126.952673@grasshopper.cs.duke.edu> <20020619233721.A30669@unixdaemons.com> <15633.62357.79381.405511@grasshopper.cs.duke.edu> <20020620114511.A22413@unixdaemons.com> <15634.534.696063.241224@grasshopper.cs.duke.edu> <20020620134723.A22954@unixdaemons.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bosko Milekic writes: > > One question. I've observed some really anomolous behaviour under > > -stable with my Myricom GM driver (2Gb/s + 2Gb/s link speed, Dual 1GHz > > pIII). When I use 4K mbufs for receives, the best speed I see is > > about 1300Mb/sec. However, if I use private 9K physically contiguous > > buffers I see 1850Mb/sec (iperf TCP). > > > > The obvious conclusion is that there's a lot of overhead in setting up > > the DMA engines, but that's not the case; we have a fairly quick chain > > dma engine. I've provided a "control" by breaking my contiguous > > buffers down into 4K chunks so that I do the same number of DMAs in > > both cases and I still see ~1850 Mb/sec for the 9K buffers. > > > > A coworker suggested that the problem was that when doing copyouts to > > userspace, the PIII was doing speculative reads and loading the cache > > with the next page. However, we then start copying from a totally > > different address using discontigous buffers, so we effectively take > > 2x the number of cache misses we'd need to. Does that sound > > reasonable to you? I need to try malloc'ing virtually contigous and > > physically discontigous buffers & see if I get the same (good) > > performance... > > I believe that the Intel chips do "virtual page caching" and that the > logic that does the virtual -> physical address translation sits between > the L2 cache and RAM. If that is indeed the case, then your idea of > testing with virtually contiguous pages is a good one. > Unfortunately, I don't know if the PIII is doing speculative > cache-loads, but it could very well be the case. If it is and if in > fact the chip does caching based on virtual addresses, then providing it > with virtually contiguous address space may yield better results. If > you try this, please let me know. I'm extremely interested in seeing > the results! contigmalloc'ed private jumbo mbufs (same as bge, if_ti, etc): % iperf -c ugly-my -l 32k -fm ------------------------------------------------------------ Client connecting to ugly-my, TCP port 5001 TCP window size: 0.2 MByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.3 port 1031 connected with 192.168.1.4 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 2137 MBytes 1792 Mbits/sec malloc'ed, physically discontigous private jumbo mbufs: % iperf -c ugly-my -l 32k -fm ------------------------------------------------------------ Client connecting to ugly-my, TCP port 5001 TCP window size: 0.2 MByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.3 port 1029 connected with 192.168.1.4 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 2131 MBytes 1788 Mbits/sec So I'd be willing to believe that the 4Mb/sec loss was due to the extra overhead of setting up 2 additional DMAs. So it looks like this idea would work. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 4 14:55: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E346537B405 for ; Thu, 4 Jul 2002 14:54:57 -0700 (PDT) Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40D0443E09 for ; Thu, 4 Jul 2002 14:54:57 -0700 (PDT) (envelope-from corecode@corecode.ath.cx) Received: from fwd00.sul.t-online.de by mailout07.sul.t-online.com with smtp id 17QEYw-0001rp-08; Thu, 04 Jul 2002 23:54:54 +0200 Received: from spirit.zuhause.stoert.net (320050403952-0001@[217.82.55.248]) by fmrl00.sul.t-online.com with esmtp id 17QEYq-0I5eUaC; Thu, 4 Jul 2002 23:54:48 +0200 Received: from elevation.uni.stoert.net (elevation.uni.stoert.net [10.150.180.177]) by spirit.zuhause.stoert.net (8.11.6/8.11.6) with ESMTP id g64Lsl838978; Thu, 4 Jul 2002 23:54:47 +0200 (CEST) (envelope-from corecode@elevation.uni.stoert.net) Received: (from corecode@localhost) by elevation.uni.stoert.net (8.12.3/8.12.3/Submit) id g64Lskwa000527; Thu, 4 Jul 2002 23:54:46 +0200 (CEST) (envelope-from corecode) Date: Thu, 4 Jul 2002 23:54:43 +0200 From: "Simon 'corecode' Schubert" To: Christophe Prevotaux Cc: net@FreeBSD.ORG Subject: Re: 'vr' watchdog timeout Message-Id: <20020704235443.73aed437.corecode@corecode.ath.cx> In-Reply-To: <20020704183159.3d42699a.c.prevotaux@hexanet.fr> References: <20020704183159.3d42699a.c.prevotaux@hexanet.fr> X-Mailer: Sylpheed version 0.7.8claws (GTK+ 1.2.10; i386-portbld-freebsd4.6) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=.K(N9bPNMwf(Dh9" X-Sender: 320050403952-0001@t-dialin.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --=.K(N9bPNMwf(Dh9 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 4 Jul 2002 18:31:59 +0200 Christophe Prevotaux wrote: > As others I do have the 'vr' driver bug > that will give the "watchdog timeout" message under interface heavy load > > I am using 4.6-STABLE , I am wondering if this has been fixed > yet. It is very annoying since it can bring a system down by > shutting down its network interface completely. i'm having the same problems here using a via rhine I. iirc there was a PR pointing to the (reference) linux driver by via, silby@ assigned it to himself but i don't know how far he's come with it. cheerz simon -- /"\ http://corecode.ath.cx/#donate \ / \ ASCII Ribbon Campaign / \ Against HTML Mail and News --=.K(N9bPNMwf(Dh9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9JMQmr5S+dk6z85oRAvyrAJ9LTLIGScB+a9TtCUEJ8u3ZeWo/5QCghXHz UuUlYDzHhFjLe1tJvAXiN08= =BUge -----END PGP SIGNATURE----- --=.K(N9bPNMwf(Dh9-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 4 15:15:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B10137B400; Thu, 4 Jul 2002 15:15:43 -0700 (PDT) Received: from mail.tgd.net (mail.tgd.net [209.81.25.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFB8443E31; Thu, 4 Jul 2002 15:15:42 -0700 (PDT) (envelope-from sean@mail.tgd.net) Received: by mail.tgd.net (Postfix, from userid 1001) id A459C20F01; Thu, 4 Jul 2002 15:15:41 -0700 (PDT) Date: Thu, 4 Jul 2002 15:15:41 -0700 From: Sean Chittenden To: Brooks Davis Cc: Joe Marcus Clarke , Barney Wolff , freebsd-net@FreeBSD.ORG Subject: Re: Skinny (SCCP) protocol gateway for libalias Message-ID: <20020704151541.D77084@ninja1.internal> References: <1025480857.48597.33.camel@shumai.marcuscom.com> <20020630204452.A56736@tp.databus.com> <1025485730.48597.35.camel@shumai.marcuscom.com> <20020630213704.A57193@tp.databus.com> <1025487696.48597.43.camel@shumai.marcuscom.com> <20020630202858.B10041@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020630202858.B10041@Odin.AC.HMC.Edu>; from "brooks@one-eyed-alien.net" on Sun, Jun 30, 2002 at = 08:28:58PM X-PGP-Key: 0x1EDDFAAD X-PGP-Fingerprint: C665 A17F 9A56 286C 5CFB 1DEA 9F4F 5CEF 1EDD FAAD X-Web-Homepage: http://sean.chittenden.org/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > > I knew I should have explained. :) > > > > > > What I fear is volatility, with an undocumented proprietary > > > protocol. And suppose Cisco abandons it for something > > > completely different - when would it be aged out? > > > > You bring up a good point. Volatility is something I didn't > > consider. Thanks. > > IMO you shouldn't consider it. Cisco will probably support this > protocol for years. Even if they "abandon" it, it will still be > supported because there are already sites with thousands of phone > that aren't going to upgrade on a whim. I believe it should go in. > If at some point in the future it is actually gone from real use, > then it can be removed. Ehh.. I worked for the dept in Cisco that was deploying the call manager servers for Cisco... this puppy's going to be around for a while: Cisco dumped a huge chunk of change into implementing and deploying this. They're not about to write this off as a sunk cost any time soon (unlike Unity, which got the ax). -sc -- Sean Chittenden To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 4 15:36:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C765737B409; Thu, 4 Jul 2002 15:36:50 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B58643E42; Thu, 4 Jul 2002 15:36:50 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.3/8.12.3) with ESMTP id g64Malri002582; Thu, 4 Jul 2002 15:36:47 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id g64MalUT002581; Thu, 4 Jul 2002 15:36:47 -0700 Date: Thu, 4 Jul 2002 15:36:47 -0700 From: Brooks Davis To: Sean Chittenden Cc: Brooks Davis , Joe Marcus Clarke , Barney Wolff , freebsd-net@FreeBSD.ORG Subject: Re: Skinny (SCCP) protocol gateway for libalias Message-ID: <20020704153646.A2034@Odin.AC.HMC.Edu> References: <1025480857.48597.33.camel@shumai.marcuscom.com> <20020630204452.A56736@tp.databus.com> <1025485730.48597.35.camel@shumai.marcuscom.com> <20020630213704.A57193@tp.databus.com> <1025487696.48597.43.camel@shumai.marcuscom.com> <20020630202858.B10041@Odin.AC.HMC.Edu> <20020704151541.D77084@ninja1.internal> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020704151541.D77084@ninja1.internal>; from sean@chittenden.org on Thu, Jul 04, 2002 at 03:15:41PM -0700 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 04, 2002 at 03:15:41PM -0700, Sean Chittenden wrote: > > IMO you shouldn't consider it. Cisco will probably support this > > protocol for years. Even if they "abandon" it, it will still be > > supported because there are already sites with thousands of phone > > that aren't going to upgrade on a whim. I believe it should go in. > > If at some point in the future it is actually gone from real use, > > then it can be removed. >=20 > Ehh.. I worked for the dept in Cisco that was deploying the call > manager servers for Cisco... this puppy's going to be around for a > while: Cisco dumped a huge chunk of change into implementing and > deploying this. They're not about to write this off as a sunk cost > any time soon (unlike Unity, which got the ax). -sc Exactly, between the deployed sites and the costs of building this, Cisco isn't going to abandon this any time soon. I want to see this funcionality go in since it should improve my chances of getting a real office phone in my office (which is in a seperate state from the other corporate offices). -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9JM37XY6L6fI4GtQRAq/6AJ4wShI4cwSpCcDkmbNXfJuhoq2byACbBGhb SaUNco6xoKL9sZjXCSQ8xI4= =5N6m -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 4 18:29:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 805C737B400; Thu, 4 Jul 2002 18:29:20 -0700 (PDT) Received: from amur.ru (amur.ru [195.151.156.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id F38BD43E09; Thu, 4 Jul 2002 18:29:14 -0700 (PDT) (envelope-from dek@dt.amur.ru) Received: from anubis.my.domain (ns.dt.amur.ru [194.84.87.182]) by amur.ru (8.11.6/8.11.6) with ESMTP id g651TAu11410; Fri, 5 Jul 2002 11:29:11 +1000 Received: from there (ws-0122-01.my.domain [192.168.0.110]) by anubis.my.domain (Postfix) with SMTP id B9A8A15433; Fri, 5 Jul 2002 11:29:09 +1000 (YAKST) Content-Type: text/plain; charset="koi8-r" From: Dmitry Krasnov Organization: DT International To: FreeBSD-gnats-submit@freebsd.org Subject: Can not assign alias to any POINTOPOINT interface Date: Fri, 5 Jul 2002 11:29:17 +1000 X-Mailer: KMail [version 1.3] Cc: net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020705012909.B9A8A15433@anubis.my.domain> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Submitter-Id: current-users >Originator: Dmitry Krasnov >Organization: DT Int. >Confidential: no >Synopsis: Can not assign alias to any POINTOPOINT interface >Severity: serious >Priority: high >Category: misc >Class: sw-bug >Release: FreeBSD 4.6-STABLE i386 >Environment: System: FreeBSD anubis.local 4.6-STABLE FreeBSD 4.6-STABLE #3: Tue Jun 25 11:44:54 YAKST 2002 root@anubis.local:/usr/obj/usr/src/sys/LOCAL i386 >Description: I have problem with aliases after upgrade to 4.6-STABLE. I can not assign aliases on any ppp interface: # ifconfig cx0 cx0: flags=8051 mtu 1500 ššššššššinet xxx.xx.xx.182 --> xxx.xx.xx.181 netmask 0xfffffffc # ifconfig cx0 alias xxx.xx.xx.179 netmask 0xffffffff xxx.xx.xx.181 ifconfig: ioctl(SIOCAIFADDR): File exists I tried ppp0 for the simple test and got same results on several machines with 4.6-STABLE: # ifconfig ppp0 ppp0: flags=8010 mtu 1500 # ifconfig ppp0 10.0.0.2 netmask 0xfffffff0 10.0.0.1 # ifconfig ppp0 alias 10.0.0.3 netmask 0xffffffff 10.0.0.1 ifconfig: ioctl(SIOCAIFADDR): File exists Before upgrade I've used 4.5-STABLE, cvsup'ed at 2002-02-15. šIf I boot with /kernel.old everything works fine: # uname -a FreeBSD anubis.local 4.5-STABLE FreeBSD 4.5-STABLE #1: Fri Feb 15 12:50:41 YAKT 2002 root@anubis.local:/usr/obj/usr/src/sys/LOCAL i386 ... # ifconfig cx0 cx0: flags=8051 mtu 1500 ššššššššinet xxx.xx.xx.182 --> xxx.xx.xx.181 netmask 0xfffffffc ššššššššinet xxx.xx.xx.179 --> xxx.xx.xx.181 netmask 0xffffffff Same with ppp0: ... # ifconfig ppp0 ppp0: flags=8010 mtu 1500 ššššššššinet 10.0.0.2 --> 10.0.0.1 netmask 0xfffffff0 ššššššššinet 10.0.0.3 --> 10.0.0.1 netmask 0xffffffff >How-To-Repeat: # ifconfig ppp0 10.0.0.2 netmask 0xfffffff0 10.0.0.1 # ifconfig ppp0 alias 10.0.0.3 netmask 0xffffffff 10.0.0.1 >Fix: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 4 19:39:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E1B137B400 for ; Thu, 4 Jul 2002 19:39:12 -0700 (PDT) Received: from creme-brulee.marcuscom.com (rdu57-17-158.nc.rr.com [66.57.17.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E5E043E09 for ; Thu, 4 Jul 2002 19:39:11 -0700 (PDT) (envelope-from marcus@FreeBSD.org) Received: from shumai.marcuscom.com (marcus@shumai.marcuscom.com [192.168.1.4]) by creme-brulee.marcuscom.com (8.12.5/8.12.5) with ESMTP id g652cap4032194; Thu, 4 Jul 2002 22:38:37 -0400 (EDT) (envelope-from marcus@FreeBSD.org) Subject: Re: Skinny (SCCP) protocol gateway for libalias From: Joe Marcus Clarke To: Brooks Davis Cc: Sean Chittenden , Barney Wolff , freebsd-net@FreeBSD.org In-Reply-To: <20020704153646.A2034@Odin.AC.HMC.Edu> References: <1025480857.48597.33.camel@shumai.marcuscom.com> <20020630204452.A56736@tp.databus.com> <1025485730.48597.35.camel@shumai.marcuscom.com> <20020630213704.A57193@tp.databus.com> <1025487696.48597.43.camel@shumai.marcuscom.com> <20020630202858.B10041@Odin.AC.HMC.Edu> <20020704151541.D77084@ninja1.internal> <20020704153646.A2034@Odin.AC.HMC.Edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-rJ/ddkkImRFSrOTnL1EP" X-Mailer: Ximian Evolution 1.0.7 Date: 04 Jul 2002 22:39:18 -0400 Message-Id: <1025836759.1380.109.camel@shumai.marcuscom.com> Mime-Version: 1.0 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --=-rJ/ddkkImRFSrOTnL1EP Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2002-07-04 at 18:36, Brooks Davis wrote: > On Thu, Jul 04, 2002 at 03:15:41PM -0700, Sean Chittenden wrote: > > > IMO you shouldn't consider it. Cisco will probably support this > > > protocol for years. Even if they "abandon" it, it will still be > > > supported because there are already sites with thousands of phone > > > that aren't going to upgrade on a whim. I believe it should go in. > > > If at some point in the future it is actually gone from real use, > > > then it can be removed. > >=20 > > Ehh.. I worked for the dept in Cisco that was deploying the call > > manager servers for Cisco... this puppy's going to be around for a > > while: Cisco dumped a huge chunk of change into implementing and > > deploying this. They're not about to write this off as a sunk cost > > any time soon (unlike Unity, which got the ax). -sc >=20 > Exactly, between the deployed sites and the costs of building this, > Cisco isn't going to abandon this any time soon. I want to see this > funcionality go in since it should improve my chances of getting a real > office phone in my office (which is in a seperate state from the other > corporate offices). I'll need a src committer to review and commit the patches. I am but a lowly ports committer ;-). Maybe I should file a PR.... Joe >=20 > -- Brooks >=20 > --=20 > Any statement of the form "X is the one, true Y" is FALSE. > PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --=-rJ/ddkkImRFSrOTnL1EP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQA9JQbWb2iPiv4Uz4cRAlmtAKCe0iyW7o7rdd0cG2c4VwyQ16jkUACgg3WG 45lN/bnJ8nV3eKrnepCSjDk= =49Qg -----END PGP SIGNATURE----- --=-rJ/ddkkImRFSrOTnL1EP-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 4 21:21:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E594137B400; Thu, 4 Jul 2002 21:21:14 -0700 (PDT) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4162A43E42; Thu, 4 Jul 2002 21:21:14 -0700 (PDT) (envelope-from bmilekic@angelica.unixdaemons.com) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.5/8.12.1) with ESMTP id g654KvdT006762; Fri, 5 Jul 2002 00:20:57 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host bmilekic@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.5/8.12.1/Submit) id g654KubO006761; Fri, 5 Jul 2002 00:20:56 -0400 (EDT) (envelope-from bmilekic) Date: Fri, 5 Jul 2002 00:20:56 -0400 From: Bosko Milekic To: Andrew Gallatin Cc: "Kenneth D. Merry" , current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: virtually contig jumbo mbufs (was Re: new zero copy sockets snapshot) Message-ID: <20020705002056.A5365@unixdaemons.com> References: <20020619090046.A2063@panzer.kdm.org> <20020619120641.A18434@unixdaemons.com> <15633.17238.109126.952673@grasshopper.cs.duke.edu> <20020619233721.A30669@unixdaemons.com> <15633.62357.79381.405511@grasshopper.cs.duke.edu> <20020620114511.A22413@unixdaemons.com> <15634.534.696063.241224@grasshopper.cs.duke.edu> <20020620134723.A22954@unixdaemons.com> <15652.46870.463359.853754@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <15652.46870.463359.853754@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Thu, Jul 04, 2002 at 04:59:02PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Jul 04, 2002 at 04:59:02PM -0400, Andrew Gallatin wrote: > > I believe that the Intel chips do "virtual page caching" and that the > > logic that does the virtual -> physical address translation sits between > > the L2 cache and RAM. If that is indeed the case, then your idea of > > testing with virtually contiguous pages is a good one. > > Unfortunately, I don't know if the PIII is doing speculative > > cache-loads, but it could very well be the case. If it is and if in > > fact the chip does caching based on virtual addresses, then providing it > > with virtually contiguous address space may yield better results. If > > you try this, please let me know. I'm extremely interested in seeing > > the results! > > contigmalloc'ed private jumbo mbufs (same as bge, if_ti, etc): > > % iperf -c ugly-my -l 32k -fm > ------------------------------------------------------------ > Client connecting to ugly-my, TCP port 5001 > TCP window size: 0.2 MByte (default) > ------------------------------------------------------------ > [ 3] local 192.168.1.3 port 1031 connected with 192.168.1.4 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.0 sec 2137 MBytes 1792 Mbits/sec > > > > malloc'ed, physically discontigous private jumbo mbufs: > > % iperf -c ugly-my -l 32k -fm > ------------------------------------------------------------ > Client connecting to ugly-my, TCP port 5001 > TCP window size: 0.2 MByte (default) > ------------------------------------------------------------ > [ 3] local 192.168.1.3 port 1029 connected with 192.168.1.4 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.0 sec 2131 MBytes 1788 Mbits/sec > > > So I'd be willing to believe that the 4Mb/sec loss was due to > the extra overhead of setting up 2 additional DMAs. > > > So it looks like this idea would work. Yes, it certainly confirms the virtual-based caching assumptions. I would like to provide virtually contiguous large buffers and believe I can do that via mb_alloc... however, they would be several wired-down pages. Would this be in line with the requirements that these buffers would have, in your mind? (wired-down means that your buffers will come out exactly as they would out of malloc(), so if you were using malloc() already, I'm assuming that wired-down is OK). I think I can allocate the jumbo buffers via mb_alloc from the same map as I allocate clusters from - the clust_map - and keep them in buckets/slabs in per-CPU caches, like I do for mbufs and regular clusters right now. Luigi is in the process of doing some optimisation work around mb_alloc and I'll probably be doing the SMP-specific stuff after he's done so once that's taken care of, we can take a stab at this if you think it's worth it. > Drew Regards, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 4 22:13:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A84FD37B400; Thu, 4 Jul 2002 22:13:26 -0700 (PDT) Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EB9543E3B; Thu, 4 Jul 2002 22:13:25 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: from panzer.kdm.org (localhost [127.0.0.1]) by panzer.kdm.org (8.12.5/8.12.5) with ESMTP id g655DMKi042257; Thu, 4 Jul 2002 23:13:22 -0600 (MDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.12.5/8.12.5/Submit) id g655DMPZ042256; Thu, 4 Jul 2002 23:13:22 -0600 (MDT) (envelope-from ken) Date: Thu, 4 Jul 2002 23:13:21 -0600 From: "Kenneth D. Merry" To: Bosko Milekic Cc: Andrew Gallatin , current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: virtually contig jumbo mbufs (was Re: new zero copy sockets snapshot) Message-ID: <20020704231321.A42134@panzer.kdm.org> References: <20020619090046.A2063@panzer.kdm.org> <20020619120641.A18434@unixdaemons.com> <15633.17238.109126.952673@grasshopper.cs.duke.edu> <20020619233721.A30669@unixdaemons.com> <15633.62357.79381.405511@grasshopper.cs.duke.edu> <20020620114511.A22413@unixdaemons.com> <15634.534.696063.241224@grasshopper.cs.duke.edu> <20020620134723.A22954@unixdaemons.com> <15652.46870.463359.853754@grasshopper.cs.duke.edu> <20020705002056.A5365@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020705002056.A5365@unixdaemons.com>; from bmilekic@unixdaemons.com on Fri, Jul 05, 2002 at 12:20:56AM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jul 05, 2002 at 00:20:56 -0400, Bosko Milekic wrote: > On Thu, Jul 04, 2002 at 04:59:02PM -0400, Andrew Gallatin wrote: > > > I believe that the Intel chips do "virtual page caching" and that the > > > logic that does the virtual -> physical address translation sits between > > > the L2 cache and RAM. If that is indeed the case, then your idea of > > > testing with virtually contiguous pages is a good one. > > > Unfortunately, I don't know if the PIII is doing speculative > > > cache-loads, but it could very well be the case. If it is and if in > > > fact the chip does caching based on virtual addresses, then providing it > > > with virtually contiguous address space may yield better results. If > > > you try this, please let me know. I'm extremely interested in seeing > > > the results! > > > > contigmalloc'ed private jumbo mbufs (same as bge, if_ti, etc): > > > > % iperf -c ugly-my -l 32k -fm > > ------------------------------------------------------------ > > Client connecting to ugly-my, TCP port 5001 > > TCP window size: 0.2 MByte (default) > > ------------------------------------------------------------ > > [ 3] local 192.168.1.3 port 1031 connected with 192.168.1.4 port 5001 > > [ ID] Interval Transfer Bandwidth > > [ 3] 0.0-10.0 sec 2137 MBytes 1792 Mbits/sec > > > > > > > > malloc'ed, physically discontigous private jumbo mbufs: > > > > % iperf -c ugly-my -l 32k -fm > > ------------------------------------------------------------ > > Client connecting to ugly-my, TCP port 5001 > > TCP window size: 0.2 MByte (default) > > ------------------------------------------------------------ > > [ 3] local 192.168.1.3 port 1029 connected with 192.168.1.4 port 5001 > > [ ID] Interval Transfer Bandwidth > > [ 3] 0.0-10.0 sec 2131 MBytes 1788 Mbits/sec > > > > > > So I'd be willing to believe that the 4Mb/sec loss was due to > > the extra overhead of setting up 2 additional DMAs. > > > > > > So it looks like this idea would work. > > Yes, it certainly confirms the virtual-based caching assumptions. I > would like to provide virtually contiguous large buffers and believe I > can do that via mb_alloc... however, they would be several wired-down > pages. Would this be in line with the requirements that these buffers > would have, in your mind? (wired-down means that your buffers will > come out exactly as they would out of malloc(), so if you were using > malloc() already, I'm assuming that wired-down is OK). > > I think I can allocate the jumbo buffers via mb_alloc from the same map > as I allocate clusters from - the clust_map - and keep them in > buckets/slabs in per-CPU caches, like I do for mbufs and regular > clusters right now. Luigi is in the process of doing some optimisation > work around mb_alloc and I'll probably be doing the SMP-specific stuff > after he's done so once that's taken care of, we can take a stab at > this if you think it's worth it. If you do implement this, it would also be nice to have some sort of standardized page-walking function to extract the physical addresses. (Otherwise every driver will end up implementing its own loop to do it.) We also may want to examine what sort of guarantees, if any, we can make about the physical page alignment of the allocated mbuf. i.e. if we can guarantee that the mbuf data segment will start on a physical page boundary (if it is at least a page in size), that would allow device drivers to be able to guarantee that they could fit a jumbo frame (9000 bytes) into 3 scatter/gather segments on an i386. The number of scatter/gather segments used is important for some boards, like ti(4), because they have a limited number of scatter/gather segments available. In the case of ti(4), it is 4 S/G segments, which is enough to handle the maximum number of physical data chunks it would take to compose a 9K virtual buffer. (You could start in the middle of a page, have two complete pages, and then end with a partial page.) I suppose it would be good to see what NIC drivers in the tree can receive into or send from multiple chunks of data, and what their requirements are. (how many scatter/gather segments they can handle, what is the maximum MTU, etc.) Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 4 23:45:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11A4E37B400; Thu, 4 Jul 2002 23:45:20 -0700 (PDT) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6ADC43E31; Thu, 4 Jul 2002 23:45:14 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g656ih757199; Fri, 5 Jul 2002 09:44:43 +0300 (EEST) (envelope-from ru) Date: Fri, 5 Jul 2002 09:44:43 +0300 From: Ruslan Ermilov To: Dmitry Krasnov Cc: Brian Somers , bug-followup@FreeBSD.org, net@FreeBSD.org Subject: Re: misc/40206: Can not assign alias to any POINTOPOINT interface Message-ID: <20020705064443.GA52753@sunbay.com> References: <20020705012909.B9A8A15433@anubis.my.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20020705012909.B9A8A15433@anubis.my.domain> User-Agent: Mutt/1.3.99i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The first ifconfig adds a route to 10.0.0.1 thru 10.0.0.2. The second ifconfig attempts to add a route to 10.0.0.1 thru 10.0.0.3 and fails because the route already exists. The change is caused by sys/netinet/in.c,v 1.65 (merged to RELENG_4 as 1.44.2.12). The feature that hided EEXIST from rtinit() existed in in.c in a small window between 1.44.2.4 and 1.44.2.11. This roughly comes to between 4.4-RELEASE and 4.5-RELEASE. As a workaround, you can ``route delete 10.0.0.1'' after the first ifconfig. On Fri, Jul 05, 2002 at 11:29:17AM +1000, Dmitry Krasnov wrote: > I have problem with aliases after upgrade to 4.6-STABLE. I can not assign > aliases on any ppp interface: > > # ifconfig cx0 > cx0: flags=8051 mtu 1500 >         inet xxx.xx.xx.182 --> xxx.xx.xx.181 netmask 0xfffffffc > # ifconfig cx0 alias xxx.xx.xx.179 netmask 0xffffffff xxx.xx.xx.181 > ifconfig: ioctl(SIOCAIFADDR): File exists > > I tried ppp0 for the simple test and got same results on several machines > with 4.6-STABLE: > > # ifconfig ppp0 > ppp0: flags=8010 mtu 1500 > # ifconfig ppp0 10.0.0.2 netmask 0xfffffff0 10.0.0.1 > # ifconfig ppp0 alias 10.0.0.3 netmask 0xffffffff 10.0.0.1 > ifconfig: ioctl(SIOCAIFADDR): File exists > > Before upgrade I've used 4.5-STABLE, cvsup'ed at 2002-02-15.  If I boot with > /kernel.old everything works fine: > > # uname -a > FreeBSD anubis.local 4.5-STABLE FreeBSD 4.5-STABLE #1: Fri Feb 15 12:50:41 > YAKT 2002 root@anubis.local:/usr/obj/usr/src/sys/LOCAL i386 > ... > # ifconfig cx0 > cx0: flags=8051 mtu 1500 >         inet xxx.xx.xx.182 --> xxx.xx.xx.181 netmask 0xfffffffc >         inet xxx.xx.xx.179 --> xxx.xx.xx.181 netmask 0xffffffff > > Same with ppp0: > > ... > # ifconfig ppp0 > ppp0: flags=8010 mtu 1500 >         inet 10.0.0.2 --> 10.0.0.1 netmask 0xfffffff0 >         inet 10.0.0.3 --> 10.0.0.1 netmask 0xffffffff > > >How-To-Repeat: > # ifconfig ppp0 10.0.0.2 netmask 0xfffffff0 10.0.0.1 > # ifconfig ppp0 alias 10.0.0.3 netmask 0xffffffff 10.0.0.1 -- Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 5 5: 9:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6308337B407; Fri, 5 Jul 2002 05:09:22 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 239FA43E5E; Fri, 5 Jul 2002 05:09:20 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id IAA20605; Fri, 5 Jul 2002 08:09:17 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g65C8l928851; Fri, 5 Jul 2002 08:08:47 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15653.35919.24295.698563@grasshopper.cs.duke.edu> Date: Fri, 5 Jul 2002 08:08:47 -0400 (EDT) To: Bosko Milekic Cc: "Kenneth D. Merry" , current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: virtually contig jumbo mbufs (was Re: new zero copy sockets snapshot) In-Reply-To: <20020705002056.A5365@unixdaemons.com> References: <20020619090046.A2063@panzer.kdm.org> <20020619120641.A18434@unixdaemons.com> <15633.17238.109126.952673@grasshopper.cs.duke.edu> <20020619233721.A30669@unixdaemons.com> <15633.62357.79381.405511@grasshopper.cs.duke.edu> <20020620114511.A22413@unixdaemons.com> <15634.534.696063.241224@grasshopper.cs.duke.edu> <20020620134723.A22954@unixdaemons.com> <15652.46870.463359.853754@grasshopper.cs.duke.edu> <20020705002056.A5365@unixdaemons.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bosko Milekic writes: > > Yes, it certainly confirms the virtual-based caching assumptions. I > would like to provide virtually contiguous large buffers and believe I > can do that via mb_alloc... however, they would be several wired-down > pages. Would this be in line with the requirements that these buffers > would have, in your mind? (wired-down means that your buffers will > come out exactly as they would out of malloc(), so if you were using > malloc() already, I'm assuming that wired-down is OK). I'd use these virtually contiguous, physically discontigous mbufs for GigE drivers which support jumbo frames and multiple recv descripters, but are incapable of doing header-splitting, or any other sort of useful framing (almost all of them, I think). From that perspective, it doesn't really matter what the mbufs look like internally. > I think I can allocate the jumbo buffers via mb_alloc from the same map > as I allocate clusters from - the clust_map - and keep them in > buckets/slabs in per-CPU caches, like I do for mbufs and regular > clusters right now. Luigi is in the process of doing some optimisation > work around mb_alloc and I'll probably be doing the SMP-specific stuff > after he's done so once that's taken care of, we can take a stab at > this if you think it's worth it. Would this be easier or harder than simple, physically contiguous buffers? I think that its only worth doing if its easier to manage at the system level, otherwise you might as well use physically contiguous mbufs. My main goal is to see the per-driver cache's of physical memory disappear ;) Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 5 5:21:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFB0237B400; Fri, 5 Jul 2002 05:21:29 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 240D643E3B; Fri, 5 Jul 2002 05:21:29 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id IAA20554; Fri, 5 Jul 2002 08:04:04 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g65C3Y928844; Fri, 5 Jul 2002 08:03:34 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15653.35606.290023.621040@grasshopper.cs.duke.edu> Date: Fri, 5 Jul 2002 08:03:34 -0400 (EDT) To: "Kenneth D. Merry" Cc: Bosko Milekic , current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: virtually contig jumbo mbufs (was Re: new zero copy sockets snapshot) In-Reply-To: <20020704231321.A42134@panzer.kdm.org> References: <20020619090046.A2063@panzer.kdm.org> <20020619120641.A18434@unixdaemons.com> <15633.17238.109126.952673@grasshopper.cs.duke.edu> <20020619233721.A30669@unixdaemons.com> <15633.62357.79381.405511@grasshopper.cs.duke.edu> <20020620114511.A22413@unixdaemons.com> <15634.534.696063.241224@grasshopper.cs.duke.edu> <20020620134723.A22954@unixdaemons.com> <15652.46870.463359.853754@grasshopper.cs.duke.edu> <20020705002056.A5365@unixdaemons.com> <20020704231321.A42134@panzer.kdm.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Kenneth D. Merry writes: <...> > > Yes, it certainly confirms the virtual-based caching assumptions. I > > would like to provide virtually contiguous large buffers and believe I > > can do that via mb_alloc... however, they would be several wired-down > > pages. Would this be in line with the requirements that these buffers > > would have, in your mind? (wired-down means that your buffers will > > come out exactly as they would out of malloc(), so if you were using > > malloc() already, I'm assuming that wired-down is OK). > > > > I think I can allocate the jumbo buffers via mb_alloc from the same map > > as I allocate clusters from - the clust_map - and keep them in > > buckets/slabs in per-CPU caches, like I do for mbufs and regular > > clusters right now. Luigi is in the process of doing some optimisation > > work around mb_alloc and I'll probably be doing the SMP-specific stuff > > after he's done so once that's taken care of, we can take a stab at > > this if you think it's worth it. > > If you do implement this, it would also be nice to have some sort of > standardized page-walking function to extract the physical addresses. > (Otherwise every driver will end up implementing its own loop to do it.) Good point. But this sounds like it belongs as a part of the (currently unimplemented) busdma infastructure for mbufs. > We also may want to examine what sort of guarantees, if any, we can make > about the physical page alignment of the allocated mbuf. i.e. if we can > guarantee that the mbuf data segment will start on a physical page boundary > (if it is at least a page in size), that would allow device drivers to be > able to guarantee that they could fit a jumbo frame (9000 bytes) into 3 > scatter/gather segments on an i386. > > The number of scatter/gather segments used is important for some boards, > like ti(4), because they have a limited number of scatter/gather segments > available. In the case of ti(4), it is 4 S/G segments, which is enough to > handle the maximum number of physical data chunks it would take to compose > a 9K virtual buffer. (You could start in the middle of a page, have two > complete pages, and then end with a partial page.) > > I suppose it would be good to see what NIC drivers in the tree can receive > into or send from multiple chunks of data, and what their requirements are. > (how many scatter/gather segments they can handle, what is the maximum MTU, > etc.) If you're just looking at the code, then this would be hard. All the current drivers (with the exception of em) are coded to take one physically contiguous private buffer. I'm pretty sure that most of them are capable of doing scatter DMA, but I don't have the programming docs. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 5 6:32:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5524537B400 for ; Fri, 5 Jul 2002 06:32:19 -0700 (PDT) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34F4543E3B for ; Fri, 5 Jul 2002 06:32:18 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g65DYZr25095; Fri, 5 Jul 2002 09:34:35 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Fri, 5 Jul 2002 09:34:35 -0400 From: Bosko Milekic To: Andrew Gallatin Cc: "Kenneth D. Merry" , net@FreeBSD.ORG Subject: Re: virtually contig jumbo mbufs (was Re: new zero copy sockets snapshot) Message-ID: <20020705093435.A25047@unixdaemons.com> References: <20020619120641.A18434@unixdaemons.com> <15633.17238.109126.952673@grasshopper.cs.duke.edu> <20020619233721.A30669@unixdaemons.com> <15633.62357.79381.405511@grasshopper.cs.duke.edu> <20020620114511.A22413@unixdaemons.com> <15634.534.696063.241224@grasshopper.cs.duke.edu> <20020620134723.A22954@unixdaemons.com> <15652.46870.463359.853754@grasshopper.cs.duke.edu> <20020705002056.A5365@unixdaemons.com> <15653.35919.24295.698563@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <15653.35919.24295.698563@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Fri, Jul 05, 2002 at 08:08:47AM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [ -current trimmed ] On Fri, Jul 05, 2002 at 08:08:47AM -0400, Andrew Gallatin wrote: > Would this be easier or harder than simple, physically contiguous > buffers? I think that its only worth doing if its easier to manage at > the system level, otherwise you might as well use physically > contiguous mbufs. My main goal is to see the per-driver cache's of > physical memory disappear ;) It would be much easier. The problem with getting physically contiguous memory is that shortly after the system gets going, memory becomes fragmented. So, from a system's perspective, it's very hard to get physically contiguous pages. This is why you see most drivers that actually do this sort of thing pre-allocate a pool of such beasts early on during boot up. Unfortunately, this means that they'll be eating up a lot of memory (some may stay unused forever) at a very early stage. As for the guarantee that the data region will start at a page boundary, yes I can ensure that as long as you don't tamper with offsetting the m_data field of the mbuf after the allocator hands it to you. That is, I can guarantee this: [ mbuf ] [ ] [ m_data -]--->[ jumbo buf ] [ (page 1) ] [-----------] [ (page 2) ] [-----------] [ (page 3) ] So, as you see, it is deffinately do-able to have all the jumbo bufs start at a page boundary; however, it may be more worthwhile to have some of them start later. We would have to implement it first and we would have to do some measurements to see what really works best. What I hate about jumbo bufs is that there's a lot of wastage in the last (3rd page). I can't exactly use the last half of that last page for, say, a 2K cluster, because then I wouldn't be respecting the bucket "infrastructure" in mb_alloc that allows easy implementation of page freeing. Pretty much the only "realistic" thing I could do is allocate jumbo bufs in groups of 3 or 4; this would ensure much less wastage but would mean that not all of them would start at page boundaries. > Drew Regards, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 5 7:10:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86B7037B400 for ; Fri, 5 Jul 2002 07:10:45 -0700 (PDT) Received: from rack.purplecat.net (rack.purplecat.net [208.133.44.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id B261B43E3B for ; Fri, 5 Jul 2002 07:10:44 -0700 (PDT) (envelope-from pbrezny@purplecat.net) Received: (qmail 13436 invoked from network); 5 Jul 2002 14:11:00 -0000 Received: from unknown (HELO micron) (208.150.25.130) by rack.purplecat.net with SMTP; 5 Jul 2002 14:11:00 -0000 From: "Peter Brezny" To: Subject: freebsd vs. Cisco for two t1's Date: Fri, 5 Jul 2002 10:07:32 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org We're considering bringing two more t1's into the office through a separate provider to diversify our path out. The new circuits will terminate in dc, as opposed to Atlanta where our current circuits terminate. We've got two t1 cards laying around from other systems we've pulled back, and I was wondering if anyone has had success using freebsd for nothing but terminating t1's and routing traffic. What we want: both t1's multiplexed coming into the freebsd system bgp4/eigrp to communicating with the Cisco on the other t1's so that packets always take the best path out to the internet. It would be nice to run picobsd for this system, or boot it off a flash card so as not to have to worry about drives. Any comments or suggestions are welcome. TIA Peter Brezny purplecat.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 5 7:14:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BCD837B400 for ; Fri, 5 Jul 2002 07:14:38 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F14143E31 for ; Fri, 5 Jul 2002 07:14:37 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id KAA22717; Fri, 5 Jul 2002 10:14:35 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g65EE5W28982; Fri, 5 Jul 2002 10:14:05 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15653.43437.658461.49860@grasshopper.cs.duke.edu> Date: Fri, 5 Jul 2002 10:14:05 -0400 (EDT) To: Bosko Milekic Cc: "Kenneth D. Merry" , net@FreeBSD.ORG Subject: Re: virtually contig jumbo mbufs (was Re: new zero copy sockets snapshot) In-Reply-To: <20020705093435.A25047@unixdaemons.com> References: <20020619120641.A18434@unixdaemons.com> <15633.17238.109126.952673@grasshopper.cs.duke.edu> <20020619233721.A30669@unixdaemons.com> <15633.62357.79381.405511@grasshopper.cs.duke.edu> <20020620114511.A22413@unixdaemons.com> <15634.534.696063.241224@grasshopper.cs.duke.edu> <20020620134723.A22954@unixdaemons.com> <15652.46870.463359.853754@grasshopper.cs.duke.edu> <20020705002056.A5365@unixdaemons.com> <15653.35919.24295.698563@grasshopper.cs.duke.edu> <20020705093435.A25047@unixdaemons.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bosko Milekic writes: > > [ -current trimmed ] > > On Fri, Jul 05, 2002 at 08:08:47AM -0400, Andrew Gallatin wrote: > > Would this be easier or harder than simple, physically contiguous > > buffers? I think that its only worth doing if its easier to manage at > > the system level, otherwise you might as well use physically > > contiguous mbufs. My main goal is to see the per-driver cache's of > > physical memory disappear ;) > > It would be much easier. The problem with getting physically > contiguous memory is that shortly after the system gets going, memory > becomes fragmented. So, from a system's perspective, it's very hard to > get physically contiguous pages. This is why you see most drivers that > actually do this sort of thing pre-allocate a pool of such beasts early > on during boot up. Unfortunately, this means that they'll be eating up > a lot of memory (some may stay unused forever) at a very early stage. What's worse, you might have 2 drivers, and have one driver with buffers but no load, and another with load but no buffers. And contigmalloc fails often for loadable modules. > As for the guarantee that the data region will start at a page > boundary, yes I can ensure that as long as you don't tamper with > offsetting the m_data field of the mbuf after the allocator hands it to > you. That is, I can guarantee this: > > [ mbuf ] > [ ] > [ m_data -]--->[ jumbo buf ] > [ (page 1) ] > [-----------] > [ (page 2) ] > [-----------] > [ (page 3) ] > > So, as you see, it is deffinately do-able to have all the jumbo bufs > start at a page boundary; however, it may be more worthwhile to have > some of them start later. We would have to implement it first and we > would have to do some measurements to see what really works best. > > What I hate about jumbo bufs is that there's a lot of wastage in the > last (3rd page). I can't exactly use the last half of that last page > for, say, a 2K cluster, because then I wouldn't be respecting the > bucket "infrastructure" in mb_alloc that allows easy implementation of > page freeing. Pretty much the only "realistic" thing I could do is > allocate jumbo bufs in groups of 3 or 4; this would ensure much less > wastage but would mean that not all of them would start at page > boundaries. I think this would be fine, But we'd need to know more about the hardware limitations of the popular GiGE boards out there. We know Tigon-II can handle 4 scatters, but are there any that can handle 3 but not four? Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 5 7:42:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C00537B400 for ; Fri, 5 Jul 2002 07:42:31 -0700 (PDT) Received: from tesla.distributel.net (unknown [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4D5543E31 for ; Fri, 5 Jul 2002 07:42:30 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g65EglD00539; Fri, 5 Jul 2002 10:42:47 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Fri, 5 Jul 2002 10:42:47 -0400 From: Bosko Milekic To: Andrew Gallatin Cc: "Kenneth D. Merry" , net@FreeBSD.ORG Subject: Re: virtually contig jumbo mbufs (was Re: new zero copy sockets snapshot) Message-ID: <20020705104247.A518@unixdaemons.com> References: <20020619233721.A30669@unixdaemons.com> <15633.62357.79381.405511@grasshopper.cs.duke.edu> <20020620114511.A22413@unixdaemons.com> <15634.534.696063.241224@grasshopper.cs.duke.edu> <20020620134723.A22954@unixdaemons.com> <15652.46870.463359.853754@grasshopper.cs.duke.edu> <20020705002056.A5365@unixdaemons.com> <15653.35919.24295.698563@grasshopper.cs.duke.edu> <20020705093435.A25047@unixdaemons.com> <15653.43437.658461.49860@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <15653.43437.658461.49860@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Fri, Jul 05, 2002 at 10:14:05AM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jul 05, 2002 at 10:14:05AM -0400, Andrew Gallatin wrote: > I think this would be fine, But we'd need to know more about the > hardware limitations of the popular GiGE boards out there. We know > Tigon-II can handle 4 scatters, but are there any that can handle 3 > but not four? Why would you need 4? I can absolutely guarantee that a jumbo buf will not go over 3 pages (on i386, and 2 pages on alpha). > Drew Regards, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 5 7:46:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64A1637B407 for ; Fri, 5 Jul 2002 07:46:23 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 989D343E31 for ; Fri, 5 Jul 2002 07:46:22 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id KAA23277; Fri, 5 Jul 2002 10:46:20 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g65EjoG29016; Fri, 5 Jul 2002 10:45:50 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15653.45342.299963.692216@grasshopper.cs.duke.edu> Date: Fri, 5 Jul 2002 10:45:50 -0400 (EDT) To: Bosko Milekic Cc: "Kenneth D. Merry" , net@FreeBSD.ORG Subject: Re: virtually contig jumbo mbufs (was Re: new zero copy sockets snapshot) In-Reply-To: <20020705104247.A518@unixdaemons.com> References: <20020619233721.A30669@unixdaemons.com> <15633.62357.79381.405511@grasshopper.cs.duke.edu> <20020620114511.A22413@unixdaemons.com> <15634.534.696063.241224@grasshopper.cs.duke.edu> <20020620134723.A22954@unixdaemons.com> <15652.46870.463359.853754@grasshopper.cs.duke.edu> <20020705002056.A5365@unixdaemons.com> <15653.35919.24295.698563@grasshopper.cs.duke.edu> <20020705093435.A25047@unixdaemons.com> <15653.43437.658461.49860@grasshopper.cs.duke.edu> <20020705104247.A518@unixdaemons.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bosko Milekic writes: > > On Fri, Jul 05, 2002 at 10:14:05AM -0400, Andrew Gallatin wrote: > > I think this would be fine, But we'd need to know more about the > > hardware limitations of the popular GiGE boards out there. We know > > Tigon-II can handle 4 scatters, but are there any that can handle 3 > > but not four? > > Why would you need 4? I can absolutely guarantee that a jumbo buf > will not go over 3 pages (on i386, and 2 pages on alpha). > Perhaps I misread your earlier message. I thought you wanted to be free to align them on something other than a page boundary, so as to not waste so much space. In that case you'd need 4 scatters on i386, right? Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 5 8:17:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4E9537B400 for ; Fri, 5 Jul 2002 08:17:40 -0700 (PDT) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 860F843E31 for ; Fri, 5 Jul 2002 08:17:38 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g65FL1p00617; Fri, 5 Jul 2002 11:21:01 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Fri, 5 Jul 2002 11:21:01 -0400 From: Bosko Milekic To: Andrew Gallatin Cc: "Kenneth D. Merry" , net@FreeBSD.ORG Subject: Re: virtually contig jumbo mbufs (was Re: new zero copy sockets snapshot) Message-ID: <20020705112101.A566@unixdaemons.com> References: <20020620114511.A22413@unixdaemons.com> <15634.534.696063.241224@grasshopper.cs.duke.edu> <20020620134723.A22954@unixdaemons.com> <15652.46870.463359.853754@grasshopper.cs.duke.edu> <20020705002056.A5365@unixdaemons.com> <15653.35919.24295.698563@grasshopper.cs.duke.edu> <20020705093435.A25047@unixdaemons.com> <15653.43437.658461.49860@grasshopper.cs.duke.edu> <20020705104247.A518@unixdaemons.com> <15653.45342.299963.692216@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <15653.45342.299963.692216@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Fri, Jul 05, 2002 at 10:45:50AM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jul 05, 2002 at 10:45:50AM -0400, Andrew Gallatin wrote: > > Bosko Milekic writes: > > > > On Fri, Jul 05, 2002 at 10:14:05AM -0400, Andrew Gallatin wrote: > > > I think this would be fine, But we'd need to know more about the > > > hardware limitations of the popular GiGE boards out there. We know > > > Tigon-II can handle 4 scatters, but are there any that can handle 3 > > > but not four? > > > > Why would you need 4? I can absolutely guarantee that a jumbo buf > > will not go over 3 pages (on i386, and 2 pages on alpha). > > > > Perhaps I misread your earlier message. I thought you wanted to be > free to align them on something other than a page boundary, so as to > not waste so much space. In that case you'd need 4 scatters on i386, > right? All I meant was that I wouldn't guarantee that the buffer _begins_ at a page boundary. However, it still should only span at most 3 pages on i386. Let's say for the sake of argument that we won't need more than 9212 bytes for a jumbo buffer. Let's make the buffer 4 bytes bigger so that we'll have space for a ref. counter for it too (how convenient), so we'll allocate buffers of 9212 + 4 = 9216 bytes. It's time to allocate from the map: I'll try to grab 9 pages for a total of 4 jumbo buffers each spanning at most 3 pages (this is i386). I'll start the first buffer at the beginning of the first page and it'll end ((9216 - 8192) = 1024) bytes into the third page. I'll then start the second jumbo buffer there and finish it 2048 bytes into 5th page. I would then start the 3rd jumbo buffer there and finish it 3072 bytes into the 7th page. The last jumbo buf would start there and finish at the end of the 9th page. If my calculations are correct, that means that each jumbo buffer would span exactly 3 pages, but only the first one in the grouping would begin at a page boundary. There is also minimum wastage here. Briefly: Assuming that size_of_buf >= 2 * PAGE_SIZE, this is the above: PAGE_SIZE % (size_of_buf - 2 * PAGE_SIZE) == 0 We pick size_of_buf as small as possible but enough to accomodate the MTU and, and if possible, the ref. counter. I think 9216 should be a good number. At the same time, we try to make: bufs_per_bucket = PAGE_SIZE (integer DIV) (size_of_buf - 2 * PAGE_SIZE) bufs_per_bucket fairly reasonable (i.e., not too big). In the above scenario, size_of_buf = 9216 and bufs_per_bucket = 4. Admittedly, the numbers above were cooked up, but I think that they're fairly reasonable. > Drew Cheers, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 5 8:37:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD7C437B400 for ; Fri, 5 Jul 2002 08:37:47 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2ABC643E3B for ; Fri, 5 Jul 2002 08:37:47 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id LAA24350; Fri, 5 Jul 2002 11:37:45 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g65FbF029122; Fri, 5 Jul 2002 11:37:15 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15653.48427.102047.117270@grasshopper.cs.duke.edu> Date: Fri, 5 Jul 2002 11:37:15 -0400 (EDT) To: Bosko Milekic Cc: "Kenneth D. Merry" , net@FreeBSD.ORG Subject: Re: virtually contig jumbo mbufs (was Re: new zero copy sockets snapshot) In-Reply-To: <20020705112101.A566@unixdaemons.com> References: <20020620114511.A22413@unixdaemons.com> <15634.534.696063.241224@grasshopper.cs.duke.edu> <20020620134723.A22954@unixdaemons.com> <15652.46870.463359.853754@grasshopper.cs.duke.edu> <20020705002056.A5365@unixdaemons.com> <15653.35919.24295.698563@grasshopper.cs.duke.edu> <20020705093435.A25047@unixdaemons.com> <15653.43437.658461.49860@grasshopper.cs.duke.edu> <20020705104247.A518@unixdaemons.com> <15653.45342.299963.692216@grasshopper.cs.duke.edu> <20020705112101.A566@unixdaemons.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bosko Milekic writes: > > On Fri, Jul 05, 2002 at 10:45:50AM -0400, Andrew Gallatin wrote: > > > > Bosko Milekic writes: > > > > > > On Fri, Jul 05, 2002 at 10:14:05AM -0400, Andrew Gallatin wrote: > > > > I think this would be fine, But we'd need to know more about the > > > > hardware limitations of the popular GiGE boards out there. We know > > > > Tigon-II can handle 4 scatters, but are there any that can handle 3 > > > > but not four? > > > > > > Why would you need 4? I can absolutely guarantee that a jumbo buf > > > will not go over 3 pages (on i386, and 2 pages on alpha). > > > > > > > Perhaps I misread your earlier message. I thought you wanted to be > > free to align them on something other than a page boundary, so as to > > not waste so much space. In that case you'd need 4 scatters on i386, > > right? > > All I meant was that I wouldn't guarantee that the buffer _begins_ at > a page boundary. However, it still should only span at most 3 pages > on i386. Let's say for the sake of argument that we won't need more > than 9212 bytes for a jumbo buffer. Let's make the buffer 4 bytes > bigger so that we'll have space for a ref. counter for it too (how > convenient), so we'll allocate buffers of 9212 + 4 = 9216 bytes. It's > time to allocate from the map: I'll try to grab 9 pages for a total > of 4 jumbo buffers each spanning at most 3 pages (this is i386). I'll > start the first buffer at the beginning of the first page and it'll > end ((9216 - 8192) = 1024) bytes into the third page. I'll then start > the second jumbo buffer there and finish it 2048 bytes into 5th page. > I would then start the 3rd jumbo buffer there and finish it 3072 bytes > into the 7th page. The last jumbo buf would start there and finish at > the end of the 9th page. If my calculations are correct, that means > that each jumbo buffer would span exactly 3 pages, but only the first > one in the grouping would begin at a page boundary. There is also > minimum wastage here. Briefly: > > Assuming that size_of_buf >= 2 * PAGE_SIZE, this is the above: > > PAGE_SIZE % (size_of_buf - 2 * PAGE_SIZE) == 0 > > We pick size_of_buf as small as possible but enough to accomodate the > MTU and, and if possible, the ref. counter. I think 9216 should be a > good number. At the same time, we try to make: > > bufs_per_bucket = PAGE_SIZE (integer DIV) (size_of_buf - 2 * PAGE_SIZE) > > bufs_per_bucket fairly reasonable (i.e., not too big). In the above > scenario, size_of_buf = 9216 and bufs_per_bucket = 4. > > Admittedly, the numbers above were cooked up, but I think that they're > fairly reasonable. That looks great. I hadn't realized that things would divide out so cleanly! I think you should go for it after talking to wpaul & pdeuskar (and anybody else who maintains GiGE drivers these days). Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 5 9:45: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35A2E37B400 for ; Fri, 5 Jul 2002 09:45:03 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A0B243E09 for ; Fri, 5 Jul 2002 09:45:02 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g65Gj1T68881 for ; Fri, 5 Jul 2002 09:45:01 -0700 (PDT) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.4/8.12.4/Submit) id g65Gj1lM003467; Fri, 5 Jul 2002 09:45:01 -0700 (PDT) (envelope-from jdp) Date: Fri, 5 Jul 2002 09:45:01 -0700 (PDT) Message-Id: <200207051645.g65Gj1lM003467@vashon.polstra.com> To: net@freebsd.org From: John Polstra Subject: Re: virtually contig jumbo mbufs (was Re: new zero copy sockets snapshot) In-Reply-To: <15653.35606.290023.621040@grasshopper.cs.duke.edu> References: <20020619090046.A2063@panzer.kdm.org> <20020705002056.A5365@unixdaemons.com> <20020704231321.A42134@panzer.kdm.org> <15653.35606.290023.621040@grasshopper.cs.duke.edu> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <15653.35606.290023.621040@grasshopper.cs.duke.edu>, Andrew Gallatin wrote: > Kenneth D. Merry writes: > > I suppose it would be good to see what NIC drivers in the tree can receive > > into or send from multiple chunks of data, and what their requirements are. > > (how many scatter/gather segments they can handle, what is the maximum MTU, > > etc.) > > If you're just looking at the code, then this would be hard. All the > current drivers (with the exception of em) are coded to take one > physically contiguous private buffer. I'm pretty sure that most of > them are capable of doing scatter DMA, but I don't have the > programming docs. The BCM570x chips (bge driver) definitely need a single physically contiguous buffer for each received packet. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 5 10:24:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E1F137B400 for ; Fri, 5 Jul 2002 10:24:19 -0700 (PDT) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id E32C243E42 for ; Fri, 5 Jul 2002 10:24:18 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g65HRZY00898; Fri, 5 Jul 2002 13:27:35 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Fri, 5 Jul 2002 13:27:35 -0400 From: Bosko Milekic To: John Polstra Cc: net@FreeBSD.ORG Subject: Re: virtually contig jumbo mbufs (was Re: new zero copy sockets snapshot) Message-ID: <20020705132735.A873@unixdaemons.com> References: <20020619090046.A2063@panzer.kdm.org> <20020705002056.A5365@unixdaemons.com> <20020704231321.A42134@panzer.kdm.org> <15653.35606.290023.621040@grasshopper.cs.duke.edu> <200207051645.g65Gj1lM003467@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <200207051645.g65Gj1lM003467@vashon.polstra.com>; from jdp@polstra.com on Fri, Jul 05, 2002 at 09:45:01AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jul 05, 2002 at 09:45:01AM -0700, John Polstra wrote: > The BCM570x chips (bge driver) definitely need a single physically > contiguous buffer for each received packet. This is totally ridiculous for gigE hardware, IMO. Do you know of other cards that can't do scatter gather DMA? > John > -- > John Polstra > John D. Polstra & Co., Inc. Seattle, Washington USA > "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa Regards, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 5 10:31: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11C3137B400 for ; Fri, 5 Jul 2002 10:31:04 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2053143E3B for ; Fri, 5 Jul 2002 10:31:03 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g65HV0T69099; Fri, 5 Jul 2002 10:31:00 -0700 (PDT) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.4/8.12.4/Submit) id g65HUxKW003600; Fri, 5 Jul 2002 10:30:59 -0700 (PDT) (envelope-from jdp) Date: Fri, 5 Jul 2002 10:30:59 -0700 (PDT) Message-Id: <200207051730.g65HUxKW003600@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: bmilekic@unixdaemons.com Subject: Re: virtually contig jumbo mbufs (was Re: new zero copy sockets snapshot) In-Reply-To: <20020705132735.A873@unixdaemons.com> References: <20020619090046.A2063@panzer.kdm.org> <15653.35606.290023.621040@grasshopper.cs.duke.edu> <200207051645.g65Gj1lM003467@vashon.polstra.com> <20020705132735.A873@unixdaemons.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <20020705132735.A873@unixdaemons.com>, Bosko Milekic wrote: > > On Fri, Jul 05, 2002 at 09:45:01AM -0700, John Polstra wrote: > > The BCM570x chips (bge driver) definitely need a single physically > > contiguous buffer for each received packet. > > This is totally ridiculous for gigE hardware, IMO. It's a shame, I agree, though I don't think I'd call it totally ridiculous. Support of multiple buffers per packet is practically essential for transmitting (and the BCM570x chips do support that), but it's really just a convenience for receiving. > Do you know of other cards that can't do scatter gather DMA? No, but I'm only intimately familiar with two of the drivers. The Broadcoms (bge) can gather but cannot scatter, and the Intels (em/gx) can do both. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 5 10:47:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BFE4837B400 for ; Fri, 5 Jul 2002 10:47:47 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1C1443E31 for ; Fri, 5 Jul 2002 10:47:46 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g65HliT69142; Fri, 5 Jul 2002 10:47:44 -0700 (PDT) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.4/8.12.4/Submit) id g65HliO2003668; Fri, 5 Jul 2002 10:47:44 -0700 (PDT) (envelope-from jdp) Date: Fri, 5 Jul 2002 10:47:44 -0700 (PDT) Message-Id: <200207051747.g65HliO2003668@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: bmilekic@unixdaemons.com Subject: Re: virtually contig jumbo mbufs (was Re: new zero copy sockets snapshot) In-Reply-To: <20020705132735.A873@unixdaemons.com> References: <20020619090046.A2063@panzer.kdm.org> <15653.35606.290023.621040@grasshopper.cs.duke.edu> <200207051645.g65Gj1lM003467@vashon.polstra.com> <20020705132735.A873@unixdaemons.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <20020705132735.A873@unixdaemons.com>, Bosko Milekic wrote: > > On Fri, Jul 05, 2002 at 09:45:01AM -0700, John Polstra wrote: > > The BCM570x chips (bge driver) definitely need a single physically > > contiguous buffer for each received packet. > > This is totally ridiculous for gigE hardware, IMO. WHOOPS, I'm afraid I have to correct myself. The BCM570x chips do indeed support multiple buffers for jumbo packets. I'm sorry for the earlier misinformation! John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 5 11: 6:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 965D737B400 for ; Fri, 5 Jul 2002 11:06:16 -0700 (PDT) Received: from proton.hexanet.fr (proton.hexanet.fr [81.23.32.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4BAB43E31 for ; Fri, 5 Jul 2002 11:06:15 -0700 (PDT) (envelope-from c.prevotaux@hexanet.fr) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.12.3/8.12.3) with SMTP id g65I69CE092069; Fri, 5 Jul 2002 20:06:10 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Fri, 5 Jul 2002 20:06:09 +0200 From: Christophe Prevotaux To: "Simon 'corecode' Schubert" Cc: net@FreeBSD.ORG Subject: Re: 'vr' watchdog timeout Message-Id: <20020705200609.6b36939c.c.prevotaux@hexanet.fr> In-Reply-To: <20020704235443.73aed437.corecode@corecode.ath.cx> References: <20020704183159.3d42699a.c.prevotaux@hexanet.fr> <20020704235443.73aed437.corecode@corecode.ath.cx> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-portbld-freebsd4.4) X-NCC-RegID: fr.hexanet Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I do hope that someone fixes this rapidely but the comment on the PR was a bit scary : "Fix: no idea" On Thu, 4 Jul 2002 23:54:43 +0200 "Simon 'corecode' Schubert" wrote: > On Thu, 4 Jul 2002 18:31:59 +0200 Christophe Prevotaux wrote: > > As others I do have the 'vr' driver bug > > that will give the "watchdog timeout" message under interface heavy load > > > > I am using 4.6-STABLE , I am wondering if this has been fixed > > yet. It is very annoying since it can bring a system down by > > shutting down its network interface completely. > > i'm having the same problems here using a via rhine I. iirc there was a > PR pointing to the (reference) linux driver by via, silby@ assigned it > to himself but i don't know how far he's come with it. > -- -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 61 77 72 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 5 12:26:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0734737B400 for ; Fri, 5 Jul 2002 12:26:15 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3152A43E3B for ; Fri, 5 Jul 2002 12:26:14 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id PAA29398; Fri, 5 Jul 2002 15:26:12 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g65JPgT29300; Fri, 5 Jul 2002 15:25:42 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15653.62134.521004.349089@grasshopper.cs.duke.edu> Date: Fri, 5 Jul 2002 15:25:42 -0400 (EDT) To: John Polstra Cc: net@freebsd.org, bmilekic@unixdaemons.com Subject: Re: virtually contig jumbo mbufs (was Re: new zero copy sockets snapshot) In-Reply-To: <200207051747.g65HliO2003668@vashon.polstra.com> References: <20020619090046.A2063@panzer.kdm.org> <15653.35606.290023.621040@grasshopper.cs.duke.edu> <200207051645.g65Gj1lM003467@vashon.polstra.com> <20020705132735.A873@unixdaemons.com> <200207051747.g65HliO2003668@vashon.polstra.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org John Polstra writes: > In article <20020705132735.A873@unixdaemons.com>, > Bosko Milekic wrote: > > > > On Fri, Jul 05, 2002 at 09:45:01AM -0700, John Polstra wrote: > > > The BCM570x chips (bge driver) definitely need a single physically > > > contiguous buffer for each received packet. > > > > This is totally ridiculous for gigE hardware, IMO. > > WHOOPS, I'm afraid I have to correct myself. The BCM570x chips do > indeed support multiple buffers for jumbo packets. I'm sorry for the > earlier misinformation! Are programming docs for this board available? BTW, it looks like nge will do scatter/gather too. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 5 12:37:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC87537B400 for ; Fri, 5 Jul 2002 12:37:11 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFBB843E31 for ; Fri, 5 Jul 2002 12:37:10 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g65Jb6T69530; Fri, 5 Jul 2002 12:37:06 -0700 (PDT) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.4/8.12.4/Submit) id g65Jb6rm003934; Fri, 5 Jul 2002 12:37:06 -0700 (PDT) (envelope-from jdp) Date: Fri, 5 Jul 2002 12:37:06 -0700 (PDT) Message-Id: <200207051937.g65Jb6rm003934@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: gallatin@cs.duke.edu Subject: Re: virtually contig jumbo mbufs (was Re: new zero copy sockets snapshot) In-Reply-To: <15653.62134.521004.349089@grasshopper.cs.duke.edu> References: <20020619090046.A2063@panzer.kdm.org> <20020705132735.A873@unixdaemons.com> <200207051747.g65HliO2003668@vashon.polstra.com> <15653.62134.521004.349089@grasshopper.cs.duke.edu> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <15653.62134.521004.349089@grasshopper.cs.duke.edu>, Andrew Gallatin wrote: > > WHOOPS, I'm afraid I have to correct myself. The BCM570x chips do > > indeed support multiple buffers for jumbo packets. I'm sorry for the > > earlier misinformation! > > Are programming docs for this board available? To get them you have to execute an NDA with Broadcom. So we're effectively limited to what can be gleaned from the Linux driver. Its header file has a struct declaration for the "T3_EXT_RCV_BD" (extended receive buffer descriptor, probably) but the driver doesn't actually use it. Without the docs it would take a lot of trial & error to figure out how to make it work. In other words, I doubt that the bge driver could use a new buffer API unless it provided a way to get physically contiguous buffers. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 5 13:21:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B860437B400 for ; Fri, 5 Jul 2002 13:21:33 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C6EC43E31 for ; Fri, 5 Jul 2002 13:21:29 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id QAA00655; Fri, 5 Jul 2002 16:11:37 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g65KB7929339; Fri, 5 Jul 2002 16:11:07 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15653.64859.690620.421707@grasshopper.cs.duke.edu> Date: Fri, 5 Jul 2002 16:11:07 -0400 (EDT) To: John Polstra Cc: net@freebsd.org Subject: Re: virtually contig jumbo mbufs (was Re: new zero copy sockets snapshot) In-Reply-To: <200207051937.g65Jb6rm003934@vashon.polstra.com> References: <20020619090046.A2063@panzer.kdm.org> <20020705132735.A873@unixdaemons.com> <200207051747.g65HliO2003668@vashon.polstra.com> <15653.62134.521004.349089@grasshopper.cs.duke.edu> <200207051937.g65Jb6rm003934@vashon.polstra.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org John Polstra writes: > In article <15653.62134.521004.349089@grasshopper.cs.duke.edu>, > Andrew Gallatin wrote: > > > WHOOPS, I'm afraid I have to correct myself. The BCM570x chips do > > > indeed support multiple buffers for jumbo packets. I'm sorry for the > > > earlier misinformation! > > > > Are programming docs for this board available? > > To get them you have to execute an NDA with Broadcom. So we're > effectively limited to what can be gleaned from the Linux driver. Its > header file has a struct declaration for the "T3_EXT_RCV_BD" (extended > receive buffer descriptor, probably) but the driver doesn't actually > use it. Without the docs it would take a lot of trial & error to > figure out how to make it work. Not necessarily. It just looked at the struct def. To me, it looks *exactly* like the equivalent tigon-2 struct. This makes sense, as its a descendant of the tigon-2. It should work just fine.. (easy for me to say, as I don't have a card to test it on). Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 5 13:50:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 115D737B401 for ; Fri, 5 Jul 2002 13:50:34 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7264C43E3B for ; Fri, 5 Jul 2002 13:50:33 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g65KoUT69873; Fri, 5 Jul 2002 13:50:30 -0700 (PDT) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.4/8.12.4/Submit) id g65KoUVY004018; Fri, 5 Jul 2002 13:50:30 -0700 (PDT) (envelope-from jdp) Date: Fri, 5 Jul 2002 13:50:30 -0700 (PDT) Message-Id: <200207052050.g65KoUVY004018@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: gallatin@cs.duke.edu Subject: Re: virtually contig jumbo mbufs (was Re: new zero copy sockets snapshot) In-Reply-To: <15653.64859.690620.421707@grasshopper.cs.duke.edu> References: <20020619090046.A2063@panzer.kdm.org> <15653.62134.521004.349089@grasshopper.cs.duke.edu> <200207051937.g65Jb6rm003934@vashon.polstra.com> <15653.64859.690620.421707@grasshopper.cs.duke.edu> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <15653.64859.690620.421707@grasshopper.cs.duke.edu>, Andrew Gallatin wrote: > > Without the docs it would take a lot of trial & error to > > figure out how to make it work. > > Not necessarily. It just looked at the struct def. To me, it looks > *exactly* like the equivalent tigon-2 struct. This makes sense, as > its a descendant of the tigon-2. Are the tigon-2 docs publicly available and free from NDA concerns? John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 5 13:54:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A64C37B400 for ; Fri, 5 Jul 2002 13:54:55 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF7F543E09 for ; Fri, 5 Jul 2002 13:54:54 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id QAA01438; Fri, 5 Jul 2002 16:54:54 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g65KsOR29409; Fri, 5 Jul 2002 16:54:24 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15654.1920.185037.569964@grasshopper.cs.duke.edu> Date: Fri, 5 Jul 2002 16:54:24 -0400 (EDT) To: John Polstra Cc: net@freebsd.org Subject: Re: virtually contig jumbo mbufs In-Reply-To: <200207052050.g65KoUVY004018@vashon.polstra.com> References: <20020619090046.A2063@panzer.kdm.org> <15653.62134.521004.349089@grasshopper.cs.duke.edu> <200207051937.g65Jb6rm003934@vashon.polstra.com> <15653.64859.690620.421707@grasshopper.cs.duke.edu> <200207052050.g65KoUVY004018@vashon.polstra.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org John Polstra writes: > In article <15653.64859.690620.421707@grasshopper.cs.duke.edu>, > Andrew Gallatin wrote: > > > Without the docs it would take a lot of trial & error to > > > figure out how to make it work. > > > > Not necessarily. It just looked at the struct def. To me, it looks > > *exactly* like the equivalent tigon-2 struct. This makes sense, as > > its a descendant of the tigon-2. > > Are the tigon-2 docs publicly available and free from NDA concerns? They used to be, before alteon was aquired by Broadcom. That's how the if_ti.c driver was written, and how Ken & I did the zero-copy work. The zero-copy if_ti.c uses extended recv. buffers. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 5 19:12:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 299F137B400 for ; Fri, 5 Jul 2002 19:12:54 -0700 (PDT) Received: from Clarke.i-pi.com (Clarke.i-pi.com [198.49.217.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 699D743E09 for ; Fri, 5 Jul 2002 19:12:53 -0700 (PDT) (envelope-from ingham@Clarke.i-pi.com) Received: from Clarke.i-pi.com (localhost [127.0.0.1]) by Clarke.i-pi.com (8.12.3/8.12.3) with ESMTP id g662CqeC006313 for ; Fri, 5 Jul 2002 20:12:52 -0600 (MDT) (envelope-from ingham@Clarke.i-pi.com) Received: (from ingham@localhost) by Clarke.i-pi.com (8.12.4/8.12.4/Submit) id g662Cplk006312 for net@freebsd.org; Fri, 5 Jul 2002 20:12:51 -0600 (MDT) Date: Fri, 5 Jul 2002 20:12:51 -0600 From: Kenneth Ingham To: net@freebsd.org Subject: Message-ID: <20020706021251.GA6301@Clarke.i-pi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org unsubscribe net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 6 6:21:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E32637B40B for ; Sat, 6 Jul 2002 06:21:22 -0700 (PDT) Received: from kwiatek.eu.org (kwiatek.eu.org [193.110.123.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B49B43E42 for ; Sat, 6 Jul 2002 06:21:21 -0700 (PDT) (envelope-from kwiatek@tpi.pl) Received: from localhost (localhost [127.0.0.1]) by kwiatek.eu.org (Postfix) with ESMTP id ECE6F32C53 for ; Sat, 6 Jul 2002 15:13:56 +0200 (CEST) Date: Sat, 6 Jul 2002 15:13:56 +0200 (CEST) From: Andrzej Kwiatkowski X-X-Sender: kwiatek@kwiatek.eu.org To: freebsd-net@freebsd.org Subject: subscribe freebsd-net Message-ID: <20020706151344.P80433-100000@kwiatek.eu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ---------- Andrzej Kwiatkowski tpinternet unix system administrator To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 6 15:19:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66C4537B400 for ; Sat, 6 Jul 2002 15:19:51 -0700 (PDT) Received: from utility.clubscholarship.com (utility.clubscholarship.com [198.78.70.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EBFA43E09 for ; Sat, 6 Jul 2002 15:19:51 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Received: from localhost (root@localhost) by utility.clubscholarship.com (8.11.6/8.11.6) with ESMTP id g66MHSi44637 for ; Sat, 6 Jul 2002 15:17:28 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Date: Sat, 6 Jul 2002 15:17:28 -0700 (PDT) From: Patrick Thomas To: Subject: Linksys USB100M ... usbd.conf help needed. Message-ID: <20020706150728.G79469-100000@utility.clubscholarship.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have just purchased a Linksys USB100M - it is a very small key-style USB NIC. I am running 5.0-DP1. I have all of the USB items except for the removable disk device compiled into my kernel - I also have the three aue/cue/kue options compiled into the kernel. I put the device in and got this message on the console: Jul 6 15:06:49 hostname kernel: ugen0: Linksys Linksys USB LAN Adapter, rev 1.10/1.00, addr 2 Then I ran `usbdevs -v`: Controller /dev/usb0: addr 1: self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 addr 2: full speed, power 120 mA, config 1, Linksys USB LAN Adapter(0x8150), Linksys(0x0bda), rev 1.00 port 2 powered Ok. So then I removed the device, and added these lines to /etc/usbd.conf: device "Linksys USB100M" vendor 0x0bda product 0x8150 release 0x0001 devname "aue0" attach "/etc/pccard_ether ${DEVNAME} start" detach "/etc/pccard_ether ${DEVNAME} stop" Now I put the device back in .... and I get the same ugen0 message as above, and nothing else happens. I tried values of aue0, cue0, kue0, aue, cue, and kue in "devname", and I tried all of those with a release value of both 0x0001 and 0x0100. In all cases, basically nothing happened...just the same console message as I showed you above, and no pccard_ether event occurring. Any pointers as to what I am doing wrong ? thanks, PT To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message