From owner-freebsd-net Wed Aug 22 22:25:30 2001 Delivered-To: freebsd-net@freebsd.org Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by hub.freebsd.org (Postfix) with SMTP id 03CF137B40F for ; Wed, 22 Aug 2001 22:25:27 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 50238 invoked by uid 3193); 23 Aug 2001 05:25:26 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 23 Aug 2001 05:25:26 -0000 Date: Thu, 23 Aug 2001 01:25:26 -0400 (EDT) From: Mike Silbersack X-Sender: To: Julian Elischer Cc: Dave Zarzycki , Subject: Re: RFC: SACK/FACK patch port to Current In-Reply-To: <3B8489F6.2F1EF3A6@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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