From owner-freebsd-arch@FreeBSD.ORG Sat Jan 15 12:52:54 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B763816A4CE for ; Sat, 15 Jan 2005 12:52:54 +0000 (GMT) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id B380B43D31 for ; Sat, 15 Jan 2005 12:52:53 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.12.9p2/8.12.9) with ESMTP id j0FCqocf089188; Sat, 15 Jan 2005 15:52:50 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.12.9p2/8.12.9/Submit) id j0FCqmh5089179; Sat, 15 Jan 2005 15:52:48 +0300 (MSK) (envelope-from yar) Date: Sat, 15 Jan 2005 15:52:48 +0300 From: Yar Tikhiy To: Luigi Rizzo Message-ID: <20050115125248.GA88256@comp.chem.msu.su> References: <18962.1104749259@critter.freebsd.dk> <20050103065715.A67451@xorpc.icir.org> <20050115103607.GA81277@comp.chem.msu.su> <20050115024930.A31992@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050115024930.A31992@xorpc.icir.org> User-Agent: Mutt/1.5.6i cc: arch@freebsd.org cc: Poul-Henning Kamp Subject: Re: Socket rate limiting (was: Re: making nmdm(4) emulate actual speed.) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2005 12:52:54 -0000 On Sat, Jan 15, 2005 at 02:49:30AM -0800, Luigi Rizzo wrote: > two comments: the reasons why apps implement throttling on their > own are > 1) portability - they cannot assume the required services > are available on the platforms they are going to run on; Software (stock daemons in particular) could benefit from having such service through using some kind of #ifdef'ed code. AFAIK, the notorious Apache httpd uses accept filters and sendfile() this way. BTW, it's a partucularly important case that an application can't use sendfile() and do throttling at the same time w/o support from the OS. > 2) scheduling and resource management - apps have their own > requirement on how to schedule things and it is often > unlikely that they can express them in term of altq/dummynet > "classes". Such OS-level rate-limiting service could be the "lowest common denominator" for simpler net apps that just want make sure a client won't get more than X bps of traffic. Then it can be extended to hierarchic classes of clients, e.g., impose an overall limit on all sockets stemming from a single listening socket etc. > This said, there is no problem in having thousands of dummynet > pipes -- the algorithms used in dummynet have O(log N) cost > where N is the number of active pipes. Thank you for your considerations! -- Yar