Date: Mon, 03 Jul 2000 10:41:17 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: dg@root.com Cc: Bosko Milekic <bmilekic@dsuper.net>, freebsd-hackers@FreeBSD.ORG Subject: Re: mbuf re-write(s), v 0.1 Message-ID: <4201.962613677@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 03 Jul 2000 01:20:15 PDT." <200007030820.BAA09516@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200007030820.BAA09516@implode.root.com>, David Greenman writes: >> I'm getting the unfortunate impression that evolution is being >> frowned upon here. Are their other people that frown the proposal out >> there to this extent? (i.e. "don't change it if it works") I'd like to >> hear some important voices on this issue so that I can decide whether to >> just drop this entire thing and forget about it. (in other words, what do >> committers and/or core have to say about this?) >> >> Aside from this, I've gotten several other "pro" opinions on this; >> some people have even sent suggestions. So I know that I am not the only >> one (not by far, in fact) to see an opportunity to benefit from this. >> Either way, I know *I* will be using this code in time to come, so I >> suppose the question is: >> Would you consider committing this code or should I stop posting any >> changes I make in the future altogether? > > What I'm doing is challenging your assertions that spending CPU cycles to >save memory in the networking code is the right thing to do. I'm further >saying that I have direct experiance in this area since I'm one of the primary >people in FreeBSD's history that have spent major amounts of effort in >improving its performance, especially in the networking area. David, not all FreeBSD systems come with 128MB ram or more. We have a significant market of very small systems where a different policy might make a lot more sense. I agree that real numbers will have to be used to make any decisions however. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4201.962613677>