From owner-freebsd-net@FreeBSD.ORG Wed Sep 24 14:50:34 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A64E81065681; Wed, 24 Sep 2008 14:50:34 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 7B9148FC26; Wed, 24 Sep 2008 14:50:34 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 1951F167432; Wed, 24 Sep 2008 10:50:34 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 24 Sep 2008 10:50:34 -0400 X-Sasl-enc: p2i1TMHZ5Gd0kvnMH1CsHXgN+IrZ3XyHTONCopQ1Rvg/ 1222267833 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 8E0A5594E; Wed, 24 Sep 2008 10:50:33 -0400 (EDT) Message-ID: <48DA53B8.3030407@FreeBSD.org> Date: Wed, 24 Sep 2008 15:50:32 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: gnn@freebsd.org References: In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Proposed patch, convert IFQ_MAXLEN to kernel tunable... 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: Wed, 24 Sep 2008 14:50:34 -0000 Hi, I agree with the intent of the change that IPv4 and IPv6 input queues should have a tunable queue length. However, the change provided is going to make the definition of IFQ_MAXLEN global and dependent upon a variable. gnn@freebsd.org wrote: > Hi, > > It turns out that the last time anyone looked at this constant was > before 1994 and it's very likely time to turn it into a kernel > tunable. On hosts that have a high rate of packet transmission > packets can be dropped at the interface queue because this value is > too small. Rather than make a sweeping code change I propose the > following change to the macro and updating a couple of places in the > IP and IPv6 stacks that were using this macro to set their own global > variables. > This isn't appropriate for many uses of ifq's which might be internal to a given driver or subsystem, and which may use IFQ_MAXLEN for convenience, as Ruslan has pointed out. I have code elsewhere which does this. Can you please do this on a per-protocol stack basis? i.e. give IPv4 and IPv6 their own TUNABLE queue length. thanks BMS