Date: Thu, 23 Aug 2001 01:25:26 -0400 (EDT) From: Mike Silbersack <silby@silby.com> To: Julian Elischer <julian@elischer.org> Cc: Dave Zarzycki <zarzycki@freebsd.org>, <freebsd-net@freebsd.org> Subject: Re: RFC: SACK/FACK patch port to Current Message-ID: <Pine.BSF.4.30.0108230119410.46046-100000@niwun.pair.com> In-Reply-To: <3B8489F6.2F1EF3A6@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 22 Aug 2001, Julian Elischer wrote: > Mike Silbersack wrote: > > However, before that is done, I think some changes should be made; all the > > #ifdef SACK and #ifdef FACKs are ugly. They should be taken out, and > > runtime tuneables (defaulting to on) should be added around the pieces of > > code that actually control SACK and FACK initialization at socket setup > > time. This will ensure that it gets wide testing, and at the same time > > will allow people who suspect that it is causing problems to still turn it > > off. > > > > Once those changes are made, it's probably best to have 2-3 other > > committers test and review before committing. > > I usually add a new feature with #ifdefs for the first few weeks > and take them out after I'm confident that it's safe.. > > | __--_|\ Julian Elischer | \ U \/ / hard at work in > | / \ julian@elischer.org +------>x USA \ a very strange In general, I agree that #ifdefing new code is be a good idea. However, from a quick readthrough of the patch I got the impression that the SACK code is effectively conditionalized on a per-pcb basis. (It would have to be, actually.) While a quick review or two won't tell us if the SACK implementation is perfect, I'm sure we'll be able to tell if sysctls disabling SACK will make the stack act in its current fashion. Perhaps I went overboard in saying that the sysctl should be on by default, though. We could leave it turned off until significant testing has been done. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.30.0108230119410.46046-100000>