From owner-freebsd-net@FreeBSD.ORG Sat Jul 5 12:33:37 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 6649937B401 for ; Sat, 5 Jul 2003 12:33:37 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5B9343FE1 for ; Sat, 5 Jul 2003 12:33:36 -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 h65JXakN062810; Sat, 5 Jul 2003 12:33:36 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h65JXWoF062809; Sat, 5 Jul 2003 12:33:32 -0700 (PDT) (envelope-from rizzo) Date: Sat, 5 Jul 2003 12:33:32 -0700 From: Luigi Rizzo To: Eugene Grosbein Message-ID: <20030705123332.A60972@xorpc.icir.org> References: <20030703002247.A2097@grosbein.pp.ru> <3F0310CE.5070302@tenebras.com> <3F03867A.79F82968@kuzbass.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F03867A.79F82968@kuzbass.ru>; from eugen@kuzbass.ru on Thu, Jul 03, 2003 at 09:27:22AM +0800 cc: Eugene Grosbein cc: net@freebsd.org Subject: 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: Sat, 05 Jul 2003 19:33:37 -0000 sorry for the late reply... [thread about prioritizing packet at the bottleneck interface] On Thu, Jul 03, 2003 at 09:27:22AM +0800, Eugene Grosbein wrote: ... > In addition to dummynet WFQ queue there is interface FIFO queue. unfortunately, there are actually two queues -- one is struct ifnet:struct ifqueue if_snd, which is always present; the other one is the 'transmit ring' (or various other names) which is sometimes just one or two slots, and sometimes a long list of buffers that the hardware drains as conditions permit. Certain hardware even has multiple, prioritized transmit rings, but there is no support for them in our drivers (basically we don't have an API for that). Typically (but this is device dependent) the output routines punch through if_snd and enqueue directly into the transmit ring, and when that fills up the driver switches mode of operation and queues into if_snd, until the hardware signals that the transmit ring has room available, drains if_snd and the driver returns to the previous mode. Now, the 'transmit ring not full' condition is very driver-dependent, some only assert it when the ring is completely empty, others when there is one slot available, others when there are some empty slot. Bottom line -- the whole architecture has been designed with FIFO in mind, and implementing any different queueing policy will involve some significant rewriting of the device drivers, plus, potentially, some significant performance loss. [BTW speaking of this, just have a look at how convoluted is the function red_drops() in dummynet, and that is for a "simple" marking algorithm. Prioritizing packets involves a lot more synchronization with the device because you might need to change the next packet to transmit even if there are some already queued]. cheers luigi > Always, even in the absence of dummynet :-) > It keeps packets that cannot be transmitted immediately > because device is busy. And FIFO, by definition, > will not allow prioritized packets to go out before others. > > Eugene > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"