From owner-freebsd-net@FreeBSD.ORG Tue Jul 8 02:09:28 2003 Return-Path: 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 D8AE637B401 for ; Tue, 8 Jul 2003 02:09:28 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DBAF43FB1 for ; Tue, 8 Jul 2003 02:09:28 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.8p1/8.12.3) with ESMTP id h6899SkN093920; Tue, 8 Jul 2003 02:09:28 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h6899RrM093919; Tue, 8 Jul 2003 02:09:27 -0700 (PDT) (envelope-from rizzo) Date: Tue, 8 Jul 2003 02:09:27 -0700 From: Luigi Rizzo To: Bruce M Simpson Message-ID: <20030708020927.A89198@xorpc.icir.org> References: <20030703002247.A2097@grosbein.pp.ru> <3F0310CE.5070302@tenebras.com> <3F03867A.79F82968@kuzbass.ru> <20030705123332.A60972@xorpc.icir.org> <20030707201247.GG32325@spc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030707201247.GG32325@spc.org>; from bms@spc.org on Mon, Jul 07, 2003 at 09:12:47PM +0100 cc: Eugene Grosbein cc: net@freebsd.org Subject: QoS/device API (was Re: ipprecedence) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2003 09:09:29 -0000 On Mon, Jul 07, 2003 at 09:12:47PM +0100, Bruce M Simpson wrote: ... > With the increased interest in VoIP and similar these days, perhaps hardware > DS/QoS support of this nature is something the project should explore? the usual problem here is that if you want your mechanisms to be useful, you should implement them in software first (even though it has a performance impact), and then exploit the hw capabilities when/if they are present and useful (e.g. on a slow link and fast CPU, you don't care too much about separate hw queues). The 'if_tx_rdy' dummynet trick that i mentioned does cover the software part, and i believe it can be made reasonably cheap (i.e. skip the function call if no pipes are registered to be clocked by that interface) so that it will not harm performance in the general case. If there is interest, i can look into doing this change and adding this call to our device drivers. cheers luigi