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