From owner-freebsd-net Fri May 1 11:59:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA01227 for freebsd-net-outgoing; Fri, 1 May 1998 11:59:32 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA01182; Fri, 1 May 1998 11:59:15 -0700 (PDT) (envelope-from pb@fasterix.frmug.org) Received: (from uucp@localhost) by frmug.org (8.9.0.Beta7/frmug-2.3/nospam) with UUCP id UAA02542; Fri, 1 May 1998 20:58:46 +0200 (CEST) (envelope-from pb@fasterix.frmug.org) Received: (from pb@localhost) by fasterix.frmug.org (8.8.8/8.8.5/pb-19970302) id UAA00996; Fri, 1 May 1998 20:58:34 +0200 (CEST) Message-ID: <19980501205833.A655@fasterix.frmug.fr.net> Date: Fri, 1 May 1998 20:58:33 +0200 From: Pierre Beyssac To: Garrett Wollman Cc: freebsd-current@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Fwd: NetBSD network code improvements References: <19980501152245.A1890@fasterix.frmug.fr.net> <199805011550.KAA02206@friley585.res.iastate.edu> <19980501185444.LR22034@@> <199805011813.OAA08910@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.92.2 In-Reply-To: <199805011813.OAA08910@khavrinen.lcs.mit.edu>; from Garrett Wollman on Fri, May 01, 1998 at 02:13:51PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ discussion copied to freebsd-net, please remove -current when replying ] On Fri, May 01, 1998 at 02:13:51PM -0400, Garrett Wollman wrote: > We should think carefully about what WE actually WANT to do (which is > not necessarily the same as what NASA is paying Jason to do). I think A lot of their stuff is generally useful, the MTU discovery stuff for example (although I don't exactly know what is in -current and maybe we don't need to integrate NetBSD stuff). The fast forwarding stuff is useful for people using FreeBSD as a fast router. It is modular enough that I ported it in 2 hours, and I'm currently running it. Everything is in one file (ip_flow.c) and you just need to add hooks calling it when receiving packets from the interfaces. Works ok for me so far between PPP and my ethernet (which doesn't say much about the performance improvement :-)). I'll send the patches to the list soon. The only problem that I see is that it clutters up the kernel even if you don't use it (in NetBSD, it is compiled in only if you have the GATEWAY option, but you can't do that in FreeBSD since it's a kernel configuration variable). We should probably make it an explicit option but other than that I don't see any reason for not taking it. The bpf stuff is useful for userland application programmers. My understanding is that it's the same for the socket zero-copy stuff. I haven't looked at these yet. -- Pierre Beyssac pb@fasterix.frmug.org pb@fasterix.freenix.org {Free,Net,Open}BSD, Linux : il y a moins bien, mais c'est plus cher Free domains: http://www.eu.org/ or mail dns-manager@EU.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 1 12:20:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA04083 for freebsd-net-outgoing; Fri, 1 May 1998 12:20:00 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from pop.uniserve.com (pop.uniserve.com [204.244.156.3]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA04050 for ; Fri, 1 May 1998 12:19:53 -0700 (PDT) (envelope-from tom@uniserve.com) Received: from shell.uniserve.ca [204.244.186.218] by pop.uniserve.com with smtp (Exim 1.82 #4) id 0yVLLJ-0006Jr-00; Fri, 1 May 1998 12:19:33 -0700 Date: Fri, 1 May 1998 12:19:31 -0700 (PDT) From: Tom X-Sender: tom@shell.uniserve.ca To: Pierre Beyssac cc: Garrett Wollman , freebsd-net@FreeBSD.ORG Subject: Re: Fwd: NetBSD network code improvements In-Reply-To: <19980501205833.A655@fasterix.frmug.fr.net> 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 Fri, 1 May 1998, Pierre Beyssac wrote: > [ discussion copied to freebsd-net, please remove -current when replying ] > > On Fri, May 01, 1998 at 02:13:51PM -0400, Garrett Wollman wrote: > > We should think carefully about what WE actually WANT to do (which is > > not necessarily the same as what NASA is paying Jason to do). > > I think A lot of their stuff is generally useful, the MTU discovery > stuff for example (although I don't exactly know what is in -current > and maybe we don't need to integrate NetBSD stuff). FreeBSD has had path MTU for a long time. It also correctly expired old cloned routes. I think in this area we are ahead of NetBSD. That is what makes it so complex. > The fast forwarding stuff is useful for people using FreeBSD as a > fast router. It is modular enough that I ported it in 2 hours, and > I'm currently running it. Everything is in one file (ip_flow.c) > and you just need to add hooks calling it when receiving packets > from the interfaces. Works ok for me so far between PPP and my > ethernet (which doesn't say much about the performance improvement Well, if you are running PPP over any kind of high speed serial, it would be useful. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 1 13:25:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA14594 for freebsd-net-outgoing; Fri, 1 May 1998 13:25:55 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA14533; Fri, 1 May 1998 13:25:42 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id PAA04029; Fri, 1 May 1998 15:25:02 -0500 (EST) (envelope-from toor) Message-Id: <199805012025.PAA04029@dyson.iquest.net> Subject: Re: Fwd: NetBSD network code improvements In-Reply-To: <19980501205833.A655@fasterix.frmug.fr.net> from Pierre Beyssac at "May 1, 98 08:58:33 pm" To: pb@fasterix.freenix.org (Pierre Beyssac) Date: Fri, 1 May 1998 15:25:02 -0500 (EST) Cc: wollman@khavrinen.lcs.mit.edu, freebsd-current@FreeBSD.ORG, freebsd-net@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (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 Remember, if we take anything from NetBSD, we need to fully credit them. Even though some "teams" are very liberal with other's ideas, lets (the FreeBSD team) not get into that habit. > > It is modular enough that I ported it in 2 hours, and > I'm currently running it. Everything is in one file (ip_flow.c) > and you just need to add hooks calling it when receiving packets > from the interfaces. Works ok for me so far between PPP and my > ethernet (which doesn't say much about the performance improvement > :-)). I'll send the patches to the list soon. The only problem that > I see is that it clutters up the kernel even if you don't use it > (in NetBSD, it is compiled in only if you have the GATEWAY option, > but you can't do that in FreeBSD since it's a kernel configuration > variable). We should probably make it an explicit option but other > than that I don't see any reason for not taking it. > > The bpf stuff is useful for userland application programmers. My > understanding is that it's the same for the socket zero-copy stuff. > I haven't looked at these yet. > -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 1 13:40:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA18156 for freebsd-net-outgoing; Fri, 1 May 1998 13:40:50 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA18119 for ; Fri, 1 May 1998 13:40:36 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id MAA00654; Fri, 1 May 1998 12:35:05 -0700 (PDT) Message-Id: <199805011935.MAA00654@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Pierre Beyssac cc: Garrett Wollman , freebsd-net@FreeBSD.ORG Subject: Re: Fwd: NetBSD network code improvements In-reply-to: Your message of "Fri, 01 May 1998 20:58:33 +0200." <19980501205833.A655@fasterix.frmug.fr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 May 1998 12:35:02 -0700 From: Mike Smith Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > The fast forwarding stuff is useful for people using FreeBSD as a > fast router. It is modular enough that I ported it in 2 hours, and > I'm currently running it. Everything is in one file (ip_flow.c) > and you just need to add hooks calling it when receiving packets > from the interfaces. Works ok for me so far between PPP and my > ethernet (which doesn't say much about the performance improvement > :-)). I'll send the patches to the list soon. The only problem that > I see is that it clutters up the kernel even if you don't use it > (in NetBSD, it is compiled in only if you have the GATEWAY option, > but you can't do that in FreeBSD since it's a kernel configuration > variable). We should probably make it an explicit option but other > than that I don't see any reason for not taking it. I'm not sure that making it optional would be taking best advantage of it. If it's a standard performance-enhancing feature, we'd be best off adopting it as such, in line with our out-of-the-box philosophy, no? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 1 13:43:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA18718 for freebsd-net-outgoing; Fri, 1 May 1998 13:43:55 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA18678 for ; Fri, 1 May 1998 13:43:49 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.8/8.8.8) id QAA09515; Fri, 1 May 1998 16:43:38 -0400 (EDT) (envelope-from wollman) Date: Fri, 1 May 1998 16:43:38 -0400 (EDT) From: Garrett Wollman Message-Id: <199805012043.QAA09515@khavrinen.lcs.mit.edu> To: Mike Smith Cc: freebsd-net@FreeBSD.ORG Subject: Re: Fwd: NetBSD network code improvements In-Reply-To: <199805011935.MAA00654@dingo.cdrom.com> References: <19980501205833.A655@fasterix.frmug.fr.net> <199805011935.MAA00654@dingo.cdrom.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > I'm not sure that making it optional would be taking best advantage of > it. If it's a standard performance-enhancing feature, we'd be best off > adopting it as such, in line with our out-of-the-box philosophy, no? The code which will give the best performance on a router is not necessarily the code which will give the best performance on a host. Ergo, we should optimize for the common case. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 1 13:46:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA19042 for freebsd-net-outgoing; Fri, 1 May 1998 13:46:20 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA18986 for ; Fri, 1 May 1998 13:46:02 -0700 (PDT) (envelope-from pb@fasterix.frmug.org) Received: (from uucp@localhost) by frmug.org (8.9.0.Beta7/frmug-2.3/nospam) with UUCP id WAA08731; Fri, 1 May 1998 22:42:54 +0200 (CEST) (envelope-from pb@fasterix.frmug.org) Received: (from pb@localhost) by fasterix.frmug.org (8.8.8/8.8.5/pb-19970302) id WAA03751; Fri, 1 May 1998 22:42:40 +0200 (CEST) Message-ID: <19980501224240.B619@fasterix.frmug.fr.net> Date: Fri, 1 May 1998 22:42:40 +0200 From: Pierre Beyssac To: Mike Smith , Pierre Beyssac Cc: Garrett Wollman , freebsd-net@FreeBSD.ORG Subject: Re: Fwd: NetBSD network code improvements References: <19980501205833.A655@fasterix.frmug.fr.net> <199805011935.MAA00654@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.92.2 In-Reply-To: <199805011935.MAA00654@dingo.cdrom.com>; from Mike Smith on Fri, May 01, 1998 at 12:35:02PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, May 01, 1998 at 12:35:02PM -0700, Mike Smith wrote: > I'm not sure that making it optional would be taking best advantage of > it. If it's a standard performance-enhancing feature, we'd be best off > adopting it as such, in line with our out-of-the-box philosophy, no? Well, you have to use your machine as a router between fast interfaces for it to be really useful. It's a tradeoff as usual, it eats an additional 2Kb in the kernel. Maybe we can make it an option activated by default then, for people wanting to save 2K on their kernel... -- Pierre Beyssac pb@fasterix.frmug.org pb@fasterix.freenix.org {Free,Net,Open}BSD, Linux : il y a moins bien, mais c'est plus cher Free domains: http://www.eu.org/ or mail dns-manager@EU.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 1 13:51:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA19609 for freebsd-net-outgoing; Fri, 1 May 1998 13:51:08 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA19579 for ; Fri, 1 May 1998 13:50:45 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id MAA00700; Fri, 1 May 1998 12:45:36 -0700 (PDT) Message-Id: <199805011945.MAA00700@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Garrett Wollman cc: Mike Smith , freebsd-net@FreeBSD.ORG Subject: Re: Fwd: NetBSD network code improvements In-reply-to: Your message of "Fri, 01 May 1998 16:43:38 EDT." <199805012043.QAA09515@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 May 1998 12:45:35 -0700 From: Mike Smith Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > < said: > > > I'm not sure that making it optional would be taking best advantage of > > it. If it's a standard performance-enhancing feature, we'd be best off > > adopting it as such, in line with our out-of-the-box philosophy, no? > > The code which will give the best performance on a router is not > necessarily the code which will give the best performance on a host. > Ergo, we should optimize for the common case. Given that there is no "common case", but rather a set of cases weighted by "commonness", we're talking about a tradeoff, not a black/ white decision. If the code offers a pessimisation in all but the routing case, sure. But if it's as simple as switching function vectors based on the ip forwarding sysctl, the human factor issues should not be neglected. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 1 13:54:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA20131 for freebsd-net-outgoing; Fri, 1 May 1998 13:54:26 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from mailwall.nwest.mccaw.com (mailwall.attws.com [155.176.34.35]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA20029 for ; Fri, 1 May 1998 13:54:11 -0700 (PDT) (envelope-from eric.webster@attws.com) Received: from viruswall.entp.attws.com by mailwall.nwest.mccaw.com (8.8.8/AT&T Wireless Services, Inc. V8 version 2) id NAA22649; Fri, 1 May 1998 13:53:42 -0700 (PDT) Received: from nwestmail.nwest.mccaw.com by viruswall.entp.attws.com (8.8.8/AT&T Wireless Services, Inc. V8 version 2) id NAA09290; Fri, 1 May 1998 13:53:41 -0700 (PDT) Received: by nwestmail.nwest.mccaw.com (8.6.12/McCaw V8 version 1) id NAA18340; Fri, 1 May 1998 13:53:40 -0700 Received: from hq-msg01.nwest.mccaw.com by nwestmail.nwest.mccaw.com (8.6.12/McCaw V8 version 1) id NAA18334; Fri, 1 May 1998 13:53:40 -0700 Received: by hq-msg01.nwest.mccaw.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BD7508.876010D0@hq-msg01.nwest.mccaw.com>; Fri, 1 May 1998 13:53:32 -0700 Message-ID: From: "Webster, Eric" To: "'freebsd-net@FreeBSD.ORG'" Date: Fri, 1 May 1998 13:53:31 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org auth 381676f0 subscribe freebsd-net eric.webster@attws.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 1 14:00:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA21383 for freebsd-net-outgoing; Fri, 1 May 1998 14:00:29 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA21116 for ; Fri, 1 May 1998 13:59:39 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.8/8.8.8) id QAA09644; Fri, 1 May 1998 16:59:28 -0400 (EDT) (envelope-from wollman) Date: Fri, 1 May 1998 16:59:28 -0400 (EDT) From: Garrett Wollman Message-Id: <199805012059.QAA09644@khavrinen.lcs.mit.edu> To: Mike Smith Cc: Garrett Wollman , freebsd-net@FreeBSD.ORG Subject: Re: Fwd: NetBSD network code improvements In-Reply-To: <199805011945.MAA00700@dingo.cdrom.com> References: <199805012043.QAA09515@khavrinen.lcs.mit.edu> <199805011945.MAA00700@dingo.cdrom.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Given that there is no "common case", but rather a set of cases > weighted by "commonness" We're talking 95% to 5% here... if not more. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 1 14:06:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA22414 for freebsd-net-outgoing; Fri, 1 May 1998 14:06:42 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA22400 for ; Fri, 1 May 1998 14:06:23 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id NAA00757; Fri, 1 May 1998 13:01:52 -0700 (PDT) Message-Id: <199805012001.NAA00757@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Garrett Wollman cc: Mike Smith , freebsd-net@FreeBSD.ORG Subject: Re: Fwd: NetBSD network code improvements In-reply-to: Your message of "Fri, 01 May 1998 16:59:28 EDT." <199805012059.QAA09644@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 May 1998 13:01:52 -0700 From: Mike Smith Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > < said: > > > Given that there is no "common case", but rather a set of cases > > weighted by "commonness" > > We're talking 95% to 5% here... if not more. There aren't enough numbers there. Do you know how much the new code "hurts"? I certainly haven't seen any figures yet; it seems to me to be rather prejudicial to bias too far one way or the other just yet. My point was simply that in the spirit of anti-bloat, we need to consider anti-complex too. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 1 15:03:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA01234 for freebsd-net-outgoing; Fri, 1 May 1998 15:03:58 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA01214 for ; Fri, 1 May 1998 15:03:44 -0700 (PDT) (envelope-from pb@fasterix.frmug.org) Received: (from uucp@localhost) by frmug.org (8.9.0.Beta7/frmug-2.3/nospam) with UUCP id AAA12542; Sat, 2 May 1998 00:03:39 +0200 (CEST) (envelope-from pb@fasterix.frmug.org) Received: (from pb@localhost) by fasterix.frmug.org (8.8.8/8.8.5/pb-19970302) id AAA06708; Sat, 2 May 1998 00:03:19 +0200 (CEST) Message-ID: <19980502000319.A6171@fasterix.frmug.fr.net> Date: Sat, 2 May 1998 00:03:19 +0200 From: Pierre Beyssac To: freebsd-net@FreeBSD.ORG Cc: regnauld@deepo.prosa.dk Subject: please test: fast forwarding patches Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="pWyiEgJYm5f9v55/" X-Mailer: Mutt 0.92.2 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Here are the patches to port Matt Thomas' NetBSD fast forwarding code to -current. You need to add ip_flow.c (provided as an attachment) to /sys/netinet/ip_flow.c. It would really help if someone could make a few performance tests on a machine with fast interfaces, as I myself only have a dialup modem on one side an a 10Mbps ethernet on the other :-) In these patches, fast forwarding is always activated (variable ipflow_active == 1). I don't understand how it was done in the original code as the variable is not external, initialized to 0 and never changed from ip_flow.c. I'm going to try making this setting a sysctl. Is there any objection on my committing this when it's ready (i.e. when the sysctl is added) ? Index: conf/files =================================================================== RCS file: /home/ncvs/src/sys/conf/files,v retrieving revision 1.136 diff -u -r1.136 files --- files 1998/04/22 18:12:29 1.136 +++ files 1998/05/01 21:42:44 @@ -268,6 +268,7 @@ netinet/ip_auth.c optional ipfilter inet netinet/ip_divert.c optional ipdivert netinet/ip_fil.c optional ipfilter inet +netinet/ip_flow.c optional inet netinet/ip_frag.c optional ipfilter inet netinet/ip_fw.c optional ipfirewall netinet/ip_icmp.c optional inet Index: net/if_ethersubr.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_ethersubr.c,v retrieving revision 1.47 diff -u -r1.47 if_ethersubr.c --- if_ethersubr.c 1998/03/30 09:51:39 1.47 +++ if_ethersubr.c 1998/05/01 21:44:02 @@ -502,6 +502,8 @@ #ifdef INET case ETHERTYPE_IP: schednetisr(NETISR_IP); + if (ipflow_fastforward(m)) + return; inq = &ipintrq; break; Index: net/if_fddisubr.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_fddisubr.c,v retrieving revision 1.27 diff -u -r1.27 if_fddisubr.c --- if_fddisubr.c 1998/03/30 09:51:44 1.27 +++ if_fddisubr.c 1998/05/01 21:44:28 @@ -533,6 +533,8 @@ switch (type) { #ifdef INET case ETHERTYPE_IP: + if (ipflow_fastforward(m)) + return; schednetisr(NETISR_IP); inq = &ipintrq; break; Index: net/if_ppp.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_ppp.c,v retrieving revision 1.56 diff -u -r1.56 if_ppp.c --- if_ppp.c 1998/04/06 11:43:10 1.56 +++ if_ppp.c 1998/05/01 21:45:04 @@ -1488,6 +1488,11 @@ m->m_pkthdr.len -= PPP_HDRLEN; m->m_data += PPP_HDRLEN; m->m_len -= PPP_HDRLEN; + if (proto == PPP_IP) + if (ipflow_fastforward(m)) { + sc->sc_last_recv = time_second; + return; + } schednetisr(NETISR_IP); inq = &ipintrq; sc->sc_last_recv = time_second; /* update time of last pkt rcvd */ Index: netinet/in_var.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/in_var.h,v retrieving revision 1.27 diff -u -r1.27 in_var.h --- in_var.h 1997/09/07 05:26:43 1.27 +++ in_var.h 1998/05/01 21:45:22 @@ -211,6 +211,7 @@ IN_NEXT_MULTI((step), (inm)); \ } while(0) +struct route; struct in_multi *in_addmulti __P((struct in_addr *, struct ifnet *)); void in_delmulti __P((struct in_multi *)); int in_control __P((struct socket *, int, caddr_t, struct ifnet *, @@ -219,6 +220,9 @@ void ip_input __P((struct mbuf *)); int in_ifadown __P((struct ifaddr *ifa)); void in_ifscrub __P((struct ifnet *, struct in_ifaddr *)); +int ipflow_fastforward __P((struct mbuf *)); +void ipflow_create __P((const struct route *, struct mbuf *)); +void ipflow_slowtimo __P((void)); #endif /* KERNEL */ Index: netinet/ip_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v retrieving revision 1.82 diff -u -r1.82 ip_input.c --- ip_input.c 1998/04/13 17:27:08 1.82 +++ ip_input.c 1998/05/01 21:45:57 @@ -80,7 +80,7 @@ static int ip_rsvp_on; struct socket *ip_rsvpd; -static int ipforwarding = 0; +int ipforwarding = 0; SYSCTL_INT(_net_inet_ip, IPCTL_FORWARDING, forwarding, CTLFLAG_RW, &ipforwarding, 0, ""); Index: netinet/ip_var.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_var.h,v retrieving revision 1.34 diff -u -r1.34 ip_var.h --- ip_var.h 1997/09/07 05:26:46 1.34 +++ ip_var.h 1998/05/01 21:46:01 @@ -132,6 +132,7 @@ u_long ips_fragdropped; /* frags dropped (dups, out of space) */ u_long ips_fragtimeout; /* fragments timed out */ u_long ips_forward; /* packets forwarded */ + u_long ips_fastforward; /* packets fast forwarded */ u_long ips_cantforward; /* packets rcvd for unreachable dest */ u_long ips_redirectsent; /* packets forwarded on same net */ u_long ips_noproto; /* unknown or unsupported protocol */ @@ -150,6 +151,21 @@ u_long ips_notmember; /* multicasts for unregistered grps */ }; +#define IPFLOW_HASHBITS 6 /* should not be a multiple of 8 */ +struct ipflow { + LIST_ENTRY(ipflow) ipf_next; /* next ipflow in bucket */ + struct in_addr ipf_dst; /* destination address */ + struct in_addr ipf_src; /* source address */ + u_int8_t ipf_tos; /* type-of-service */ + struct route ipf_ro; /* associated route entry */ + u_long ipf_uses; /* number of uses in this period */ + u_long ipf_last_uses; /* number of uses in last period */ + u_long ipf_dropped; /* ENOBUFS returned by if_output */ + u_long ipf_errors; /* other errors returned by if_output */ + int ipf_timer; /* remaining lifetime of this entry */ + time_t ipf_start; /* creation time */ +}; + #ifdef KERNEL /* flags passed to ip_output as last parameter */ #define IP_FORWARDING 0x1 /* most of ip header exists */ @@ -163,6 +179,7 @@ extern struct ipstat ipstat; extern u_short ip_id; /* ip packet ctr, for ids */ extern int ip_defttl; /* default IP ttl */ +extern int ipforwarding; /* ip forwarding */ extern u_char ip_protox[]; extern struct socket *ip_rsvpd; /* reservation protocol daemon */ extern struct socket *ip_mrouter; /* multicast routing daemon */ -- Pierre Beyssac pb@fasterix.frmug.org pb@fasterix.freenix.org {Free,Net,Open}BSD, Linux : il y a moins bien, mais c'est plus cher Free domains: http://www.eu.org/ or mail dns-manager@EU.org --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ip_flow.c" /* $NetBSD: ip_flow.c,v 1.1 1998/04/29 21:37:55 matt Exp $ */ /*- * Copyright (c) 1998 The NetBSD Foundation, Inc. * All rights reserved. * * This code is derived from software contributed to The NetBSD Foundation * by the 3am Software Foundry ("3am"). It was developed by Matt Thomas. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * This product includes software developed by the NetBSD * Foundation, Inc. and its contributors. * 4. Neither the name of The NetBSD Foundation nor the names of its * contributors may be used to endorse or promote products derived * from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE * POSSIBILITY OF SUCH DAMAGE. */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #define IPFLOW_TIMER (5 * PR_SLOWHZ) #define IPFLOW_HASHSIZE (1 << IPFLOW_HASHBITS) static LIST_HEAD(ipflowhead, ipflow) ipflows[IPFLOW_HASHSIZE]; static int ipflow_inuse; #define IPFLOW_MAX 256 static int ipflow_active = 1; MALLOC_DEFINE(M_IPFLOW, "ip_flow", "IP flow"); static unsigned ipflow_hash( struct in_addr dst, struct in_addr src, unsigned tos) { unsigned hash = tos; int idx; for (idx = 0; idx < 32; idx += IPFLOW_HASHBITS) hash += (dst.s_addr >> (32 - idx)) + (src.s_addr >> idx); return hash & (IPFLOW_HASHSIZE-1); } static struct ipflow * ipflow_lookup( const struct ip *ip) { unsigned hash; struct ipflow *ipf; hash = ipflow_hash(ip->ip_dst, ip->ip_src, ip->ip_tos); ipf = LIST_FIRST(&ipflows[hash]); while (ipf != NULL) { if (ip->ip_dst.s_addr == ipf->ipf_dst.s_addr && ip->ip_src.s_addr == ipf->ipf_src.s_addr && ip->ip_tos == ipf->ipf_tos) break; ipf = LIST_NEXT(ipf, ipf_next); } return ipf; } int ipflow_fastforward( struct mbuf *m) { struct ip *ip; struct ipflow *ipf; struct rtentry *rt; u_int32_t sum; int error; /* * Are we forwarding packets? Big enough for an IP packet? */ if (!ipforwarding || !ipflow_active || m->m_len < sizeof(struct ip)) return 0; /* * IP header with no option and valid version and length */ ip = mtod(m, struct ip *); if (ip->ip_v != IPVERSION || ip->ip_hl != (sizeof(struct ip) >> 2) || ntohs(ip->ip_len) > m->m_pkthdr.len) return 0; /* * Find a flow. */ if ((ipf = ipflow_lookup(ip)) == NULL) return 0; /* * Route and interface still up? */ rt = ipf->ipf_ro.ro_rt; if ((rt->rt_flags & RTF_UP) == 0 || (rt->rt_ifp->if_flags & IFF_UP) == 0) return 0; /* * Packet size OK? TTL? */ if (m->m_pkthdr.len > rt->rt_ifp->if_mtu || ip->ip_ttl <= IPTTLDEC) return 0; /* * Everything checks out and so we can forward this packet. * Modify the TTL and incrementally change the checksum. * On little endian machine, the TTL is in LSB position * (so we can simply add) while on big-endian it's in the * MSB position (so we have to do two calculation; the first * is the add and second is to wrap the results into 17 bits, * 16 bits and a carry). */ ip->ip_ttl -= IPTTLDEC; #if BYTE_ORDER == LITTLE_ENDIAN sum = ip->ip_sum + IPTTLDEC; #endif #if BYTE_ORDER == BIG_ENDIAN sum = ip->ip_sum + (IPTTLDEC << 8); sum = (sum & 0xFFFF) + (sum >> 16); #endif if (sum > 0x10000) /* add in carry if needed */ sum++; ip->ip_sum = sum; /* bit 16 is dropped */ /* * Send the packet on its way. All we can get back is ENOBUFS */ ipf->ipf_uses++; ipf->ipf_timer = IPFLOW_TIMER; if ((error = (*rt->rt_ifp->if_output)(rt->rt_ifp, m, &ipf->ipf_ro.ro_dst, rt)) != 0) { if (error == ENOBUFS) ipf->ipf_dropped++; else ipf->ipf_errors++; } return 1; } static void ipflow_addstats( struct ipflow *ipf) { ipf->ipf_ro.ro_rt->rt_use += ipf->ipf_uses; ipstat.ips_cantforward += ipf->ipf_errors + ipf->ipf_dropped; ipstat.ips_forward += ipf->ipf_uses; ipstat.ips_fastforward += ipf->ipf_uses; } static void ipflow_free( struct ipflow *ipf) { int s; /* * Remove the flow from the hash table (at elevated IPL). * Once it's off the list, we can deal with it at normal * network IPL. */ s = splimp(); LIST_REMOVE(ipf, ipf_next); splx(s); ipflow_addstats(ipf); RTFREE(ipf->ipf_ro.ro_rt); ipflow_inuse--; FREE(ipf, M_IPFLOW); } static struct ipflow * ipflow_reap( void) { struct ipflow *ipf, *maybe_ipf = NULL; int idx; int s; for (idx = 0; idx < IPFLOW_HASHSIZE; idx++) { ipf = LIST_FIRST(&ipflows[idx]); while (ipf != NULL) { /* * If this no longer points to a valid route * reclaim it. */ if ((ipf->ipf_ro.ro_rt->rt_flags & RTF_UP) == 0) goto done; /* * choose the one that's been least recently used * or has had the least uses in the last 1.5 * intervals. */ if (ipf == NULL || ipf->ipf_timer < maybe_ipf->ipf_timer || (ipf->ipf_timer == maybe_ipf->ipf_timer && ipf->ipf_last_uses + ipf->ipf_uses < maybe_ipf->ipf_last_uses + maybe_ipf->ipf_uses)) maybe_ipf = ipf; ipf = LIST_NEXT(ipf, ipf_next); } } ipf = maybe_ipf; done: /* * Remove the entry from the flow table. */ s = splimp(); LIST_REMOVE(ipf, ipf_next); splx(s); ipflow_addstats(ipf); RTFREE(ipf->ipf_ro.ro_rt); return ipf; } void ipflow_slowtimo( void) { struct ipflow *ipf; int idx; for (idx = 0; idx < IPFLOW_HASHSIZE; idx++) { ipf = LIST_FIRST(&ipflows[idx]); while (ipf != NULL) { struct ipflow *next_ipf = LIST_NEXT(ipf, ipf_next); if (--ipf->ipf_timer == 0) { ipflow_free(ipf); } else { ipf->ipf_last_uses = ipf->ipf_uses; ipf->ipf_ro.ro_rt->rt_use += ipf->ipf_uses; ipstat.ips_forward += ipf->ipf_uses; ipstat.ips_fastforward += ipf->ipf_uses; ipf->ipf_uses = 0; } ipf = next_ipf; } } } void ipflow_create( const struct route *ro, struct mbuf *m) { const struct ip *const ip = mtod(m, struct ip *); struct ipflow *ipf; unsigned hash; int s; /* * Don't create cache entries for ICMP messages. */ if (!ipflow_active || ip->ip_p == IPPROTO_ICMP) return; /* * See if an existing flow struct exists. If so remove it from it's * list and free the old route. If not, try to malloc a new one * (if we aren't at our limit). */ ipf = ipflow_lookup(ip); if (ipf == NULL) { if (ipflow_inuse == IPFLOW_MAX) { ipf = ipflow_reap(); } else { ipf = (struct ipflow *) malloc(sizeof(*ipf), M_IPFLOW, M_NOWAIT); if (ipf == NULL) return; ipflow_inuse++; } bzero((caddr_t) ipf, sizeof(*ipf)); } else { s = splimp(); LIST_REMOVE(ipf, ipf_next); splx(s); ipflow_addstats(ipf); RTFREE(ipf->ipf_ro.ro_rt); ipf->ipf_uses = ipf->ipf_last_uses = 0; ipf->ipf_errors = ipf->ipf_dropped = 0; } /* * Fill in the updated information. */ ipf->ipf_ro = *ro; ro->ro_rt->rt_refcnt++; ipf->ipf_dst = ip->ip_dst; ipf->ipf_src = ip->ip_src; ipf->ipf_tos = ip->ip_tos; ipf->ipf_timer = IPFLOW_TIMER; ipf->ipf_start = time_second; /* * Insert into the approriate bucket of the flow table. */ hash = ipflow_hash(ip->ip_dst, ip->ip_src, ip->ip_tos); s = splimp(); LIST_INSERT_HEAD(&ipflows[hash], ipf, ipf_next); splx(s); } --pWyiEgJYm5f9v55/-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 1 16:31:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA14977 for freebsd-net-outgoing; Fri, 1 May 1998 16:31:55 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA14964 for ; Fri, 1 May 1998 16:31:49 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id QAA11741; Fri, 1 May 1998 16:30:17 -0700 (PDT) Message-Id: <199805012330.QAA11741@implode.root.com> To: Pierre Beyssac cc: freebsd-net@FreeBSD.ORG Subject: Re: Fwd: NetBSD network code improvements In-reply-to: Your message of "Fri, 01 May 1998 20:58:33 +0200." <19980501205833.A655@fasterix.frmug.fr.net> From: David Greenman Reply-To: dg@root.com Date: Fri, 01 May 1998 16:30:17 -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >[ discussion copied to freebsd-net, please remove -current when replying ] > >On Fri, May 01, 1998 at 02:13:51PM -0400, Garrett Wollman wrote: >> We should think carefully about what WE actually WANT to do (which is >> not necessarily the same as what NASA is paying Jason to do). > >I think A lot of their stuff is generally useful, the MTU discovery >stuff for example (although I don't exactly know what is in -current >and maybe we don't need to integrate NetBSD stuff). We've had Path MTU Discovery in FreeBSD for a couple of years now. It includes support for timing out clone routes. >The fast forwarding stuff is useful for people using FreeBSD as a >fast router. It is modular enough that I ported it in 2 hours, and >I'm currently running it. Everything is in one file (ip_flow.c) >and you just need to add hooks calling it when receiving packets >from the interfaces. Works ok for me so far between PPP and my >ethernet (which doesn't say much about the performance improvement >:-)). I'll send the patches to the list soon. The only problem that >I see is that it clutters up the kernel even if you don't use it >(in NetBSD, it is compiled in only if you have the GATEWAY option, >but you can't do that in FreeBSD since it's a kernel configuration >variable). We should probably make it an explicit option but other >than that I don't see any reason for not taking it. Yeah, that's pretty neat stuff and I'd like to see it as part of FreeBSD. I'm a bit concerned about its interaction (or lack of) with ipfw, however. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 1 16:56:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA19929 for freebsd-net-outgoing; Fri, 1 May 1998 16:56:36 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA19850 for ; Fri, 1 May 1998 16:56:22 -0700 (PDT) (envelope-from pb@fasterix.frmug.org) Received: (from uucp@localhost) by frmug.org (8.9.0.Beta7/frmug-2.3/nospam) with UUCP id BAA17067; Sat, 2 May 1998 01:56:17 +0200 (CEST) (envelope-from pb@fasterix.frmug.org) Received: (from pb@localhost) by fasterix.frmug.org (8.8.8/8.8.5/pb-19970302) id BAA10469; Sat, 2 May 1998 01:55:07 +0200 (CEST) Message-ID: <19980502015506.A5864@fasterix.frmug.fr.net> Date: Sat, 2 May 1998 01:55:06 +0200 From: Pierre Beyssac To: freebsd-net@FreeBSD.ORG Cc: regnauld@deepo.prosa.dk Subject: Re: please test: fast forwarding patches References: <19980502000319.A6171@fasterix.frmug.fr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.92.2 In-Reply-To: <19980502000319.A6171@fasterix.frmug.fr.net>; from Pierre Beyssac on Sat, May 02, 1998 at 12:03:19AM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ooops, I forgot this little patch to ip_input.c in ip_slowtimo() (+/- fuzz factor WRT previous patch). --- ip_input.c 1998/04/13 17:27:08 1.82 +++ ip_input.c 1998/05/01 23:49:50 @@ -878,6 +878,7 @@ } } } + ipflow_slowtimo(); splx(s); } -- Pierre Beyssac pb@fasterix.frmug.org pb@fasterix.freenix.org {Free,Net,Open}BSD, Linux : il y a moins bien, mais c'est plus cher Free domains: http://www.eu.org/ or mail dns-manager@EU.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 1 19:09:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA11480 for freebsd-net-outgoing; Fri, 1 May 1998 19:09:20 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA11351 for ; Fri, 1 May 1998 19:09:00 -0700 (PDT) (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id UAA23436 for freebsd-net@freebsd.org; Fri, 1 May 1998 20:08:59 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id UAA18865 for ; Fri, 1 May 1998 20:10:16 -0600 (MDT) Date: Fri, 1 May 1998 20:10:16 -0600 (MDT) From: Marc Slemko To: freebsd-net@FreeBSD.ORG Subject: Re: Fwd: NetBSD network code improvements In-Reply-To: <199805012330.QAA11741@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 Fri, 1 May 1998, David Greenman wrote: > >[ discussion copied to freebsd-net, please remove -current when replying ] > > > >On Fri, May 01, 1998 at 02:13:51PM -0400, Garrett Wollman wrote: > >> We should think carefully about what WE actually WANT to do (which is > >> not necessarily the same as what NASA is paying Jason to do). > > > >I think A lot of their stuff is generally useful, the MTU discovery > >stuff for example (although I don't exactly know what is in -current > >and maybe we don't need to integrate NetBSD stuff). > > We've had Path MTU Discovery in FreeBSD for a couple of years now. It > includes support for timing out clone routes. The one useful addition to FreeBSD PMTU-D that I can think of right now would be blackhole detection. It is a PITA and is just a workaround for broken networks that ends up badly hurting performance, but it does let things work when they otherwise wouldn't. That is good (because they work) and bad (because people don't fix the problem and just think FreeBSD is slow), but... AFAIK, NT does blackhole discovery. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 1 19:30:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA14229 for freebsd-net-outgoing; Fri, 1 May 1998 19:30:14 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from friley585.res.iastate.edu (friley585.res.iastate.edu [129.186.167.85]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA14054 for ; Fri, 1 May 1998 19:29:57 -0700 (PDT) (envelope-from ccsanady@friley585.res.iastate.edu) Received: from friley585.res.iastate.edu (loopback [127.0.0.1]) by friley585.res.iastate.edu (8.8.8/8.8.8) with ESMTP id VAA04136; Fri, 1 May 1998 21:29:37 -0500 (CDT) (envelope-from ccsanady@friley585.res.iastate.edu) Message-Id: <199805020229.VAA04136@friley585.res.iastate.edu> X-Mailer: exmh version 2.0.1 12/23/97 To: Garrett Wollman Cc: mike@smith.net.au, freebsd-net@FreeBSD.ORG Subject: Re: Fwd: NetBSD network code improvements In-reply-to: Your message of "Fri, 01 May 1998 16:43:38 EDT." <199805012043.QAA09515@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 May 1998 21:29:37 -0500 From: Chris Csanady Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >< said: > >> I'm not sure that making it optional would be taking best advantage of >> it. If it's a standard performance-enhancing feature, we'd be best off >> adopting it as such, in line with our out-of-the-box philosophy, no? > >The code which will give the best performance on a router is not >necessarily the code which will give the best performance on a host. >Ergo, we should optimize for the common case. I'd have to apree with this. Honestly, their IP fast forwarding code bothers me a bit. It looks like they use a more complex data structure than is needed, that takes more overhead in the common case to manage it. My main objection though is that this code adds a slowtimo--something that we should probably look at purging from the kernel altogether. It seems that it would be better to have the routing code participate more often, rather than walking the entire cache every slowtimo to reap ipflows, etc. I have included the ip_input() function from Van Jacobsons experimental stack as a reference. It uses an extremely simple cache, that requires little memory and only a handful of instructions that manage it. This code should actually have *very* low overhead even in the common case. I would prefer that the code were modeled after something closer to this. Chris Csanady /* * Copyright (C) 1992 by Van Jacobson * All rights reserved. */ #define HASH_BITS 11 #define HASH_SIZE (1 << HASH_BITS) #define HASH(dst) (((dst) ^ ((dst) >> HASH_BITS)) & (HASH_SIZE-1)) struct ipfwd_cache { u_long dst; /* ip address of final destination */ struct rtentry *rt; /* route to get there (forwarding) */ } ipfwd_cache[HASH_SIZE]; ip_input(p, ifp) register struct pbuf *p; register struct ifnet *ifp; { register struct ip *ip = ptod(p, struct ip *); register u_int len = p->p_len; register u_int dst; register struct ipfwd_cache *cache; register struct rtentry *rt; register int i; extern int ip_fill_fwd_cache(); if (len < sizeof(struct ip)) { ipstat.ips_tooshort++; goto bad; } if (len != ntohs(ip->ip_len)) { if (len < ntohs(ip->ip_len)) { ipstat.ips_toosmall++; goto bad; } len = ntohs(ip->ip_len); p->p_len = len; } if (*(char *)ip != ((IPVERSION << 4) | sizeof(struct ip)/4)) { if (ip->ip_v != IPVERSION) { ipstat.ips_badver++; goto bad; } i = ip->ip_hl << 2; if (i > len || i < sizeof(struct ip)) { ipstat.ips_badhlen++; goto bad; } if ((dst = ip_do_options(p, ip)) == 0) goto bad; } else dst = ip->ip_dst.s_addr; cache = &ipfwd_cache[HASH(dst)]; if (cache->dst != dst) { if (ip_fill_fwd_cache(p, dst, cache)) goto bad; if (ifp == rt->ifp) ip_send_redirect(p, ip, rt); } if (rt = cache->rt) { i = ip->ip_ttl; if (--i <= 0) { ip_send_time_exceeded(p); return; } ip->ip_ttl = i; i = (int)ip->ip_sum + 256; ip->ip_sum = i + (i >> 16); ifp = rt->rt_ifp; if (ifp->if_mtu < len) { /* fragment and send packet */ } else if (p = (ifp->if_pmove)(ifp, p)) (rt->rt_output)(rt, p); } else { i = ip->ip_hl << 2; p->p_data += i; p->p_len -= i; (ip_protosw[ip->ip_p])(p, ip); } return; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 1 21:33:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA03251 for freebsd-net-outgoing; Fri, 1 May 1998 21:33:14 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA03244 for ; Fri, 1 May 1998 21:33:06 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.8/8.8.8) id AAA10671; Sat, 2 May 1998 00:32:47 -0400 (EDT) (envelope-from wollman) Date: Sat, 2 May 1998 00:32:47 -0400 (EDT) From: Garrett Wollman Message-Id: <199805020432.AAA10671@khavrinen.lcs.mit.edu> To: Chris Csanady Cc: freebsd-net@FreeBSD.ORG, jtw@lcs.mit.edu Subject: Fast IP forwarding In-Reply-To: <199805020229.VAA04136@friley585.res.iastate.edu> References: <199805012043.QAA09515@khavrinen.lcs.mit.edu> <199805020229.VAA04136@friley585.res.iastate.edu> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > I have included the ip_input() function from Van Jacobsons experimental > stack as a reference. It uses an extremely simple cache, that requires > little memory and only a handful of instructions that manage it. This > code should actually have *very* low overhead even in the common case. Wow, that's a but more complicated than I would have expected from Van. Here's a slightly different take on the same concept... with some comments from eighteen months after the fact. (Some wild mutation of this may have eventually made it into the CAIRN group's sources---JTW certainly did have a copy of it when I left the fifth floor.) Note that, in a real router, you probably don't want to use a cache at all, but rather a specialized data structure that can compactly store the entire routing table and access it directly with a minimum of instructions. Or at least that's what I last heard, anyway. A couple of papers on such data structures were presented at the last SIGCOMM. /* * Ip input routine. Checksum and byte swap header. If fragmented * try to reassemble. Process options. Pass to next level. */ void ip_input(struct mbuf *m) { struct ip *ip; struct ipq *fp; struct in_ifaddr *ia; int hlen; int len, err; struct in_addr dst; struct ipfwd_cache *ipfc; struct rtentry *rt; struct ifnet *ifp; // note that we're trying to do both fast input and fast forwarding // here, depending on what sort of mood the sysadmin is in... #ifndef IPFP_ROUTER /* XXX - should do multicast faster */ /* XXX - GCC extension (pointers to labels) */ static const void *actions[] = { &&dopanic, &&fast_input, &&slow, &&fast_fwd, &&cantforward }; #endif #ifdef DIAGNOSTIC if ((m->m_flags & M_PKTHDR) == 0) panic("ip_input no HDR"); #endif /* * If no IP addresses have been set yet but the interfaces * are receiving, can't do anything with incoming packets yet. */ // this is bogus... we should still be able to receive 255.255.255.255 // broadcasts regardless of our configuration state if the netif is up. if (in_ifaddr == NULL) goto bad; ipstat.ips_total++; /* * Fast Path begins here. * Still need to worry about: * Multicast */ // note that all the special cases are handled elsewhere. // this supposedly helps branch prediction on Pentiums // and in all cases reduces the cache footprint of the // common case. if (m->m_pkthdr.len < sizeof(struct ip)) goto tooshort; // of course, with better buffering we wouldn't be playing with mbufs // so much, which would save more time and code space. #ifdef DIAGNOSTIC if (m->m_len < sizeof(struct ip)) panic("ipintr mbuf too short"); #endif ip = mtod(m, struct ip *); // IP_VHL_BORING is defined to be the right value for v4. // symbolic names are better than magic pointer dereferences... if (ip->ip_vhl != IP_VHL_BORING) { if (IP_VHL_V(ip->ip_vhl) != IPVERSION) goto badvers; hlen = IP_VHL_HL(ip->ip_vhl) << 2; if (hlen > m->m_pkthdr.len || hlen < sizeof(struct ip)) goto badhlen; // I came up with this idea independently. The experience of // source-routed multicast tunnels taught everybody that you can't // single out packets with options for really abysmal service. /* otherwise, hlen > minimum, so do options */ if (ip_fast_options(m->m_pkthdr.rcvif, m, ip, &dst)) /* can't handle these options quickly */ goto slow; } else { dst = ip->ip_dst; } len = ntohs(ip->ip_len); // in retrospect, this should probably have been handled with a `goto slow'. // only problem is short packets on Ethernets which got padded up to 64. if (m->m_pkthdr.len != len) { if (m->m_pkthdr.len < len) goto toosmall; if (m->m_len == m->m_pkthdr.len) { m->m_len = m->m_pkthdr.len = len; } else { m_adj(m, len - m->m_pkthdr.len); } } // now you see why I introduced this wrinkle two years ago... #ifdef COMPAT_IPFW if (ip_fw_chk_ptr) goto slow; #endif ipfc = &ipfwd_cache[ipf_hash(dst)]; // we don't bother filling the cache in the fast path -- just kick // over to the slow path and it will do it for us as a documented // side-effect. if we're playing router, this will also allow us // to input those packets which are actually addressed to us (since // the action member doesn't exist in that case) if (ipfc->dst.s_addr != dst.s_addr || !(rt = ipfc->rt) || !(rt->rt_flags & RTF_UP)) goto slow; // if we're not playing router, do whatever action is suggested by the // cache.... #ifndef IPFP_ROUTER if (ipfc->action > ipfp_cantforward) goto dopanic; goto *actions[ipfc->action]; /* XXX GCC extension */ #endif fast_fwd: ifp = rt->rt_ifp; if (m->m_pkthdr.rcvif == ifp) goto slow; /* maybe we should do fast redirects? */ /* * RSVP requires that we intercept all RSVP packets * passing through and feed them to the local daemon. * This will go away when we have router alert. */ if (rsvp_on && ip->ip_p == IPPROTO_RSVP) #ifdef IPFP_ROUTER goto slow; #else goto fast_input; #endif if (ifp->if_mtu <= len) goto slow; /* oops, need fragmentation */ // we make sure to keep the technically-correct behavior as an option // (but everybody knows that no routers do ip checksums on in-transit // packets these days). #if IP_FWD_CHECKSUM if (ip->ip_vhl == IP_VHL_BORING) tmpsum = ip_cksum_hdr(ip); else tmpsum = in_cksum(m, IP_VHL_HL(ip->ip_vhl) << 2); if (tmpsum) goto badsum; #endif if (--ip->ip_ttl == 0) goto send_time_exceeded; // that's what this macro (defined in ) is for... in_cksum_update(ip); // if I had done the right thing with the routing code, this would // go through the next-hop table instead and would be a trivial // `blat the header on front and send' operation most of the time. rt->rt_use++; if (rt->rt_flags & RTF_GATEWAY) { err = ifp->if_output(ifp, m, rt->rt_gateway, rt); } else { ipaddr.sin_addr = dst; err = ifp->if_output(ifp, m, (struct sockaddr *)&ipaddr, rt); } /* XXX other errors? */ if (err == EHOSTUNREACH) { /* XXX should count this */ return; } return; // I've left out the other obvious parts... -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 1 22:47:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA12124 for freebsd-net-outgoing; Fri, 1 May 1998 22:47:56 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from friley585.res.iastate.edu (friley585.res.iastate.edu [129.186.167.85]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA12100 for ; Fri, 1 May 1998 22:47:40 -0700 (PDT) (envelope-from ccsanady@friley585.res.iastate.edu) Received: from friley585.res.iastate.edu (loopback [127.0.0.1]) by friley585.res.iastate.edu (8.8.8/8.8.8) with ESMTP id AAA04760; Sat, 2 May 1998 00:47:38 -0500 (CDT) (envelope-from ccsanady@friley585.res.iastate.edu) Message-Id: <199805020547.AAA04760@friley585.res.iastate.edu> X-Mailer: exmh version 2.0.1 12/23/97 To: Garrett Wollman cc: freebsd-net@FreeBSD.ORG, jtw@lcs.mit.edu Subject: Re: Fast IP forwarding In-reply-to: Your message of "Sat, 02 May 1998 00:32:47 EDT." <199805020432.AAA10671@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 02 May 1998 00:47:38 -0500 From: Chris Csanady Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >< said: > >> I have included the ip_input() function from Van Jacobsons experimental >> stack as a reference. It uses an extremely simple cache, that requires >> little memory and only a handful of instructions that manage it. This >> code should actually have *very* low overhead even in the common case. > >Wow, that's a but more complicated than I would have expected from >Van. Here's a slightly different take on the same concept... with Really? I actually thought it quite simple. It looks as though this input routine is functionally identical, although with different syntax and a few more features. >some comments from eighteen months after the fact. (Some wild >mutation of this may have eventually made it into the CAIRN group's >sources---JTW certainly did have a copy of it when I left the fifth >floor.) Note that, in a real router, you probably don't want to use a >cache at all, but rather a specialized data structure that can >compactly store the entire routing table and access it directly with a >minimum of instructions. Or at least that's what I last heard, >anyway. A couple of papers on such data structures were presented at >the last SIGCOMM. Are you referring to the LC-trie, or something else? The LC-trie looks quite interesting. There is a bit of information on it here in case anyone gets ambitious.. http://www.cs.hut.fi/~sni/papers/router/router.html As usual, the mbuf handling is disgusting. I'm not sure I like the VHL marcos a lot either. It seems like it would be easier to read if it was just a union containing ip_vhl, and (ip_v, ip_hl). That really does not matter though I suppose. I am kindof curious though, would filling the cache in the fast path be slower than actually taking the slow path? In Van's code, the cache route entry is set to 0 for local destinations. After it is filled, no local dests would require lookups. I must say, I find the action member quite interesting. Is there a place where I can find out more about these non-standard gcc things? Regardless, I find this looks quite nice. If this is a finished work, is there any reason why it could not be integrated? -Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 1 23:06:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA13855 for freebsd-net-outgoing; Fri, 1 May 1998 23:06:08 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from friley585.res.iastate.edu (friley585.res.iastate.edu [129.186.167.85]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA13776 for ; Fri, 1 May 1998 23:06:03 -0700 (PDT) (envelope-from ccsanady@friley585.res.iastate.edu) Received: from friley585.res.iastate.edu (loopback [127.0.0.1]) by friley585.res.iastate.edu (8.8.8/8.8.8) with ESMTP id BAA04820; Sat, 2 May 1998 01:05:07 -0500 (CDT) (envelope-from ccsanady@friley585.res.iastate.edu) Message-Id: <199805020605.BAA04820@friley585.res.iastate.edu> X-Mailer: exmh version 2.0.1 12/23/97 To: dg@root.com cc: Pierre Beyssac , freebsd-net@FreeBSD.ORG Subject: Re: Fwd: NetBSD network code improvements In-reply-to: Your message of "Fri, 01 May 1998 16:30:17 PDT." <199805012330.QAA11741@implode.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 02 May 1998 01:05:07 -0500 From: Chris Csanady Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>[ discussion copied to freebsd-net, please remove -current when replying ] >> >>On Fri, May 01, 1998 at 02:13:51PM -0400, Garrett Wollman wrote: >>> We should think carefully about what WE actually WANT to do (which is >>> not necessarily the same as what NASA is paying Jason to do). >> >>I think A lot of their stuff is generally useful, the MTU discovery >>stuff for example (although I don't exactly know what is in -current >>and maybe we don't need to integrate NetBSD stuff). > > We've had Path MTU Discovery in FreeBSD for a couple of years now. It >includes support for timing out clone routes. This is sortof unrelated, but how does our syn flood code compare to the NetBSD syn cache mechanism? The syn cache code seems like a generally good idea.. >>The fast forwarding stuff is useful for people using FreeBSD as a >>fast router. It is modular enough that I ported it in 2 hours, and >>I'm currently running it. Everything is in one file (ip_flow.c) >>and you just need to add hooks calling it when receiving packets >>from the interfaces. Works ok for me so far between PPP and my >>ethernet (which doesn't say much about the performance improvement >>:-)). I'll send the patches to the list soon. The only problem that >>I see is that it clutters up the kernel even if you don't use it >>(in NetBSD, it is compiled in only if you have the GATEWAY option, >>but you can't do that in FreeBSD since it's a kernel configuration >>variable). We should probably make it an explicit option but other >>than that I don't see any reason for not taking it. > > Yeah, that's pretty neat stuff and I'd like to see it as part of FreeBSD. >I'm a bit concerned about its interaction (or lack of) with ipfw, however. Looking through NetBSD's ip_input(), they also seem to have generic hooks for packet filter type things. Perhaps these are worth looking at as well. The code is ifdef'd by PFIL_HOOKS. -Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 1 23:42:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA17120 for freebsd-net-outgoing; Fri, 1 May 1998 23:42:54 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA17115 for ; Fri, 1 May 1998 23:42:47 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id XAA17167; Fri, 1 May 1998 23:41:16 -0700 (PDT) Message-Id: <199805020641.XAA17167@implode.root.com> To: Chris Csanady cc: Pierre Beyssac , freebsd-net@FreeBSD.ORG Subject: Re: Fwd: NetBSD network code improvements In-reply-to: Your message of "Sat, 02 May 1998 01:05:07 CDT." <199805020605.BAA04820@friley585.res.iastate.edu> From: David Greenman Reply-To: dg@root.com Date: Fri, 01 May 1998 23:41:16 -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>I think A lot of their stuff is generally useful, the MTU discovery >>>stuff for example (although I don't exactly know what is in -current >>>and maybe we don't need to integrate NetBSD stuff). >> >> We've had Path MTU Discovery in FreeBSD for a couple of years now. It >>includes support for timing out clone routes. > >This is sortof unrelated, but how does our syn flood code compare to the >NetBSD syn cache mechanism? The syn cache code seems like a generally >good idea.. I think it might be more correct to say "the BSD/OS syn cache mechanism", since that's where the idea originated, although I don't know if the NetBSD code is their own or if it came from BSDI. Yes, I think the SYN cache is probably something we should have. I'm not overly thrilled, however since I think it unnecessarily obscures the code and of course slows it down a bit. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 2 08:34:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA08329 for freebsd-net-outgoing; Sat, 2 May 1998 08:34:14 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA08164 for ; Sat, 2 May 1998 08:33:58 -0700 (PDT) (envelope-from pb@fasterix.frmug.org) Received: (from uucp@localhost) by frmug.org (8.9.0.Beta7/frmug-2.3/nospam) with UUCP id RAA27428; Sat, 2 May 1998 17:33:26 +0200 (CEST) (envelope-from pb@fasterix.frmug.org) Received: (from pb@localhost) by fasterix.frmug.org (8.8.8/8.8.5/pb-19970302) id MAA19426; Sat, 2 May 1998 12:35:37 +0200 (CEST) Message-ID: <19980502123537.A324@fasterix.frmug.fr.net> Date: Sat, 2 May 1998 12:35:37 +0200 From: Pierre Beyssac To: Chris Csanady , dg@root.com Cc: freebsd-net@FreeBSD.ORG Subject: Re: Fwd: NetBSD network code improvements References: <199805012330.QAA11741@implode.root.com> <199805020605.BAA04820@friley585.res.iastate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.92.2 In-Reply-To: <199805020605.BAA04820@friley585.res.iastate.edu>; from Chris Csanady on Sat, May 02, 1998 at 01:05:07AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, May 02, 1998 at 01:05:07AM -0500, Chris Csanady wrote: > Looking through NetBSD's ip_input(), they also seem to have generic hooks > for packet filter type things. Perhaps these are worth looking at as well. > The code is ifdef'd by PFIL_HOOKS. Yes, their version of ip_fil.c uses this to get packets (it's in FreeBSD-current code too, surrounded by #ifdef NETBSD_PF). Maybe we could use it both for IPFW/IPDIVERT and IPFILTER, it could save use the multiple custom hooks we currently have for each one of them. -- Pierre Beyssac pb@fasterix.frmug.org pb@fasterix.freenix.org {Free,Net,Open}BSD, Linux : il y a moins bien, mais c'est plus cher Free domains: http://www.eu.org/ or mail dns-manager@EU.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 2 08:34:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA08400 for freebsd-net-outgoing; Sat, 2 May 1998 08:34:29 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA08353 for ; Sat, 2 May 1998 08:34:19 -0700 (PDT) (envelope-from pb@fasterix.frmug.org) Received: (from uucp@localhost) by frmug.org (8.9.0.Beta7/frmug-2.3/nospam) with UUCP id RAA27430; Sat, 2 May 1998 17:34:09 +0200 (CEST) (envelope-from pb@fasterix.frmug.org) Received: (from pb@localhost) by fasterix.frmug.org (8.8.8/8.8.5/pb-19970302) id MAA20029; Sat, 2 May 1998 12:53:09 +0200 (CEST) Message-ID: <19980502125309.B324@fasterix.frmug.fr.net> Date: Sat, 2 May 1998 12:53:09 +0200 From: Pierre Beyssac To: dg@root.com, Pierre Beyssac Cc: freebsd-net@FreeBSD.ORG Subject: Re: Fwd: NetBSD network code improvements References: <19980501205833.A655@fasterix.frmug.fr.net> <199805012330.QAA11741@implode.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.92.2 In-Reply-To: <199805012330.QAA11741@implode.root.com>; from David Greenman on Fri, May 01, 1998 at 04:30:17PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, May 01, 1998 at 04:30:17PM -0700, David Greenman wrote: > Yeah, that's pretty neat stuff and I'd like to see it as part of FreeBSD. > I'm a bit concerned about its interaction (or lack of) with ipfw, however. You're right, it bypasses ip_input/ip_output, so any filtering placed there is bypassed too. I haven't tried this, though. -- Pierre Beyssac pb@fasterix.frmug.org pb@fasterix.freenix.org {Free,Net,Open}BSD, Linux : il y a moins bien, mais c'est plus cher Free domains: http://www.eu.org/ or mail dns-manager@EU.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 2 12:30:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA10043 for freebsd-net-outgoing; Sat, 2 May 1998 12:30:40 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA10016 for ; Sat, 2 May 1998 12:30:32 -0700 (PDT) (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id NAA20366 for freebsd-net@FreeBSD.ORG; Sat, 2 May 1998 13:30:30 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id NAA24555 for ; Sat, 2 May 1998 13:30:50 -0600 (MDT) Date: Sat, 2 May 1998 13:30:50 -0600 (MDT) From: Marc Slemko To: freebsd-net@FreeBSD.ORG Subject: Re: Fwd: NetBSD network code improvements In-Reply-To: <199805020641.XAA17167@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 Fri, 1 May 1998, David Greenman wrote: > >>>I think A lot of their stuff is generally useful, the MTU discovery > >>>stuff for example (although I don't exactly know what is in -current > >>>and maybe we don't need to integrate NetBSD stuff). > >> > >> We've had Path MTU Discovery in FreeBSD for a couple of years now. It > >>includes support for timing out clone routes. > > > >This is sortof unrelated, but how does our syn flood code compare to the > >NetBSD syn cache mechanism? The syn cache code seems like a generally > >good idea.. > > I think it might be more correct to say "the BSD/OS syn cache mechanism", > since that's where the idea originated, although I don't know if the NetBSD > code is their own or if it came from BSDI. > Yes, I think the SYN cache is probably something we should have. I'm not > overly thrilled, however since I think it unnecessarily obscures the code > and of course slows it down a bit. A similar style of thing could help for TIME_WAIT too. I'm afraid I don't keep up with the FreeBSD stack as much as I would like, but a quick glance doesn't make it appear like it is there. ie. keep minimal state for TIME_WAIT, optimize the timeout handling to check less frequently for TIME_WAIT timers, etc. From what I have seen, this can make a big difference on a system with a lot of TIME_WAITs. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 2 13:06:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA13084 for freebsd-net-outgoing; Sat, 2 May 1998 13:06:56 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from mail.kersur.net (druber@mail.kersur.net [199.79.199.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA13077 for ; Sat, 2 May 1998 13:06:49 -0700 (PDT) (envelope-from druber@mail.kersur.net) Received: from localhost (druber@localhost) by mail.kersur.net (8.8.8/8.8.8) with SMTP id QAA03012 for ; Sat, 2 May 1998 16:06:52 -0400 (EDT) Date: Sat, 2 May 1998 16:06:52 -0400 (EDT) From: Dan Swartzendruber To: freebsd-net@FreeBSD.ORG Subject: weird behavior with IP aliases 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 was just helping someone set up an apache web server on a 2.2.5 box. To serve virtual domains, we decided to use IP aliasing on the ethernet interface. It works, except for one odd thing: none of the alias IPs are accessible from the web server itself. E.g. take this case: 199.1.2.1 (primary address) 199.1.2.100 (alias address) if I am on the web server (199.1.2.1), I can ping (or otherwise see) address 199.1.2.1, but any attempt to hit 199.1.2.100 fails, although other hosts on the same ethernet segment can hit that address. If I look at the routing table, I can see that 199.1.2.1 is visible via the loopback interface, but the alias isn't. The aliases were set up just as recommended in the appropriate rc files, and the ifconfig commandd is obviously being executed, but just as obviously, something else isn't. What is the missing piece here (more clearly: I known I can make this work by adding the routes myself; I'm just curious if I didn't finish setting things up 100% or if there is a bug here?) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 2 13:56:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA16457 for freebsd-net-outgoing; Sat, 2 May 1998 13:56:23 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from ns1.seidata.com (ns1.seidata.com [208.10.211.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA16444 for ; Sat, 2 May 1998 13:56:17 -0700 (PDT) (envelope-from mike@ns1.seidata.com) Received: from localhost (mike@localhost) by ns1.seidata.com (8.8.8/8.8.5) with SMTP id QAA27947; Sat, 2 May 1998 16:56:13 -0400 (EDT) Date: Sat, 2 May 1998 16:56:13 -0400 (EDT) From: Mike To: Dan Swartzendruber cc: freebsd-net@FreeBSD.ORG Subject: Re: weird behavior with IP aliases 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 On Sat, 2 May 1998, Dan Swartzendruber wrote: > I was just helping someone set up an apache web server on a 2.2.5 box. > To serve virtual domains, we decided to use IP aliasing on the ethernet [deleted] Here's the steps I take when setting up virtual domains under FreeBSD: First, I select a free IP (as you've done with 199.1.2.100). I then add a line for this ip to /usr/local/etc/rc.d/aliases.sh formatted as 'ifconfig alias netmask '. For your ip address, this could look something like (assuming vx0 int): ifconfig vx0 alias 199.1.2.100 netmask 255.255.255.255 aliases.sh will be ran at boot time, but go ahead and make this ifconfig active by just typing it at the command line... Now, 'ifconfig -a | grep 100' should show something like: inet 199.1.2.100 netmask 0xffffffff broadcast 199.1.2.100 After this, you simply make the necessary DNS and apache modifications to name and point to the domain... Good luck... Mike Hoskins SEI Data Network Services, Inc. noc@seidata.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 2 14:00:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA16896 for freebsd-net-outgoing; Sat, 2 May 1998 14:00:53 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA16887 for ; Sat, 2 May 1998 14:00:43 -0700 (PDT) (envelope-from mark@grondar.za) Received: from greenpeace.grondar.za (root@greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.8.8/8.8.8) with ESMTP id XAA13223; Sat, 2 May 1998 23:00:25 +0200 (SAST) (envelope-from mark@grondar.za) Received: from grondar.za (mark@localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.8/8.8.8) with ESMTP id XAA06689; Sat, 2 May 1998 23:00:22 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199805022100.XAA06689@greenpeace.grondar.za> To: Dan Swartzendruber cc: freebsd-net@FreeBSD.ORG Subject: Re: weird behavior with IP aliases Date: Sat, 02 May 1998 23:00:21 +0200 From: Mark Murray Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dan Swartzendruber wrote: > What is the missing piece here (more clearly: I known I can make this > work by adding the routes myself; I'm just curious if I didn't finish > setting things up 100% or if there is a bug here?) Did you make the netmask 0xffffffff? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message