From owner-freebsd-net@FreeBSD.ORG Sat Apr 1 20:57:35 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B613D16A400 for ; Sat, 1 Apr 2006 20:57:35 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70CA343D68 for ; Sat, 1 Apr 2006 20:57:32 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id k31KvJlO029252; Sat, 1 Apr 2006 12:57:19 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id k31KvIo8029251; Sat, 1 Apr 2006 12:57:18 -0800 (PST) (envelope-from rizzo) Date: Sat, 1 Apr 2006 12:57:18 -0800 From: Luigi Rizzo To: Mikhail Teterin Message-ID: <20060401125718.A28991@xorpc.icir.org> References: <200603301657.43218.mi+mx@aldan.algebra.com> <20060330140636.A98058@xorpc.icir.org> <200603311717.07894.mi+mx@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <200603311717.07894.mi+mx@aldan.algebra.com>; from mi+mx@aldan.algebra.com on Fri, Mar 31, 2006 at 05:17:07PM -0500 Cc: ugen@netvision.net.il, archie@dellroad.org, net@freebsd.org Subject: Re: Is there an API for ipfw? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2006 20:57:35 -0000 On Fri, Mar 31, 2006 at 05:17:07PM -0500, Mikhail Teterin wrote: > четвер 30 березень 2006 17:06, Luigi Rizzo написав: > > If you are doing it a lot more often, you should probably > > also consider the effect of such frequent changes to the > > pipe's configuration - e.g. pipes respond with a delay > > which is inversely proportional to the bandwidth, so in > > many cases still doesn't make sense to change the pipe's > > rate 100 times per second. > > So far I'm just playing with the rules manually. I create a pipe with: > > ipfw pipe 1 config bandwidth 22200KByte/s > > and send all NFS traffic through it with: > > ipfw add 100 pipe 1 ip from any to 172.21.128.43 dst-port 2049 > > This works most of the times, but if sometimes, when I try to change the > bandwidth from command line: > > ipfw pipe 1 config bandwidth 24MByte/s > > the NFS clients stops writing ALTOGETHER and begins logging complaints about > the NFS server (172.21.128.43) not responding. At that point, I must delete > the rule 100. The other rules are simply: > > 65533 allow ip from any to any > 65535 deny ip from any to any > > Why would altering the bandwidth slightly (up) freeze all traffic through the > pipe? Thanks! i don't know on which version of freebsd is this occurring, it would help knowning - as well as knowing if this is an UP/SMP and whether it is working as a bridge or router. Internally, dummynet computes the next tick when the pipe should be processed based on the current bandwidth (see the SET_TICKS macro in ip_dummynet.c), and when the time arrives, the computations are done using the 'new' bandwidth value (see near the beginning of funcrion 'ready_event()'. As far as i can tell (at least on 4.x) the code seems to handle changes in the bandwidth in the correct way, so the only thing i can suspect is some bug related to insufficient locking between the setsockopt and the soft interrupt handler. cheers luigi