From owner-freebsd-net Fri Nov 30 13:15:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from ardbeg.meer.net (ardbeg.meer.net [209.157.152.23]) by hub.freebsd.org (Postfix) with ESMTP id 560F937B41A for ; Fri, 30 Nov 2001 13:15:24 -0800 (PST) Received: from meer.meer.net (mail.meer.net [209.157.152.14]) by ardbeg.meer.net (8.11.3/8.11.3) with ESMTP id fAULFNp18981; Fri, 30 Nov 2001 13:15:23 -0800 (PST) Received: from neville-neil.com ([209.157.133.226]) by meer.meer.net (8.9.3/8.9.3/meer) with ESMTP id NAA3026638; Fri, 30 Nov 2001 13:14:51 -0800 (PST) Message-Id: <200111302114.NAA3026638@meer.meer.net> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Alfred Perlstein Cc: Jonathan Lemon , Jordan Hubbard , Alex Rousskov , freebsd-net@FreeBSD.ORG Subject: Re: funding TCP stack rewrite In-Reply-To: Message from Alfred Perlstein of "Fri, 30 Nov 2001 14:54:55 CST." <20011130145455.K46769@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Nov 2001 13:14:51 -0800 From: "George V. Neville-Neil" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > I don't think a rewrite is ever going to be much of a good idea, > a restructuring might, meaning that fixing up all the layering > and making it more flat like Van Jacobson suggested (and Linux > implemented in one of their stack of the year projects) might > gain us performance. I would disagree, and I'll say why in a second. > A rewrite is only necessary when you can't solve a particular > semantic or performance problem without a major kludge. Right > now we don't have any of those problems and a rewrite would > mearly throw away years apon years of testing along with making > our implementation incompatible with the texts out there which > would raise the bar for anyone attempting to base their code on > ours. Please tell me how to solve the following problems with the current stack: 1) Adding a new bit of processing in the input side of IP WITHOUT modifying ip_input. The solution should be generic. 2) Running the stack in a true multi-threaded and multi-instance environment but still within the kernel. (This is a project currently under way in several places, all commercial.) 3) Run the same stack in the kernel and in user space so that it can more easily be debugged. I submit that all of these require a rewrite and if done the resulting stack could compete quite well in the non-core router market and actually create new markets by bringing the barrier to creating incremental changes to the system down. > I agree that a rewrite without a clearly stated goal is almost always > just a euphamism for "i didn't like the variable names and indenting > of the old system" or "i want my name on the top of each file in > the sys/netinet directory". Agreed. > Lastly, I wish we just drop it until we come up with a solid reason, > all this is doing is second guessing stuff that has worked for > years. This code has existed in mostly working order for half of > my lifetime I really don't feel much anyone has the skills necessary > to duplicate the equivelant of several hundered man years of > developement in just a couple of months no matter how highly they > think of themselves. > There may not be a SINGLE solid reason, but it must be an issue otherwise it would never have come up. I think it's a good idea, if done carefully. The original TCP/IP stack and the changes since then were created in a different software era. I'm not saying to build the whole thing again in Java but I am saying that there comes a time when you have to stop putting on band aids and actually have the bone reset. Later, George To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message