Date: Sat, 1 Apr 2006 12:57:18 -0800 From: Luigi Rizzo <rizzo@icir.org> To: Mikhail Teterin <mi+mx@aldan.algebra.com> Cc: ugen@netvision.net.il, archie@dellroad.org, net@freebsd.org Subject: Re: Is there an API for ipfw? Message-ID: <20060401125718.A28991@xorpc.icir.org> In-Reply-To: <200603311717.07894.mi%2Bmx@aldan.algebra.com>; from mi%2Bmx@aldan.algebra.com on Fri, Mar 31, 2006 at 05:17:07PM -0500 References: <200603301657.43218.mi%2Bmx@aldan.algebra.com> <20060330140636.A98058@xorpc.icir.org> <200603311717.07894.mi%2Bmx@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060401125718.A28991>