From owner-freebsd-net@FreeBSD.ORG Tue Sep 23 21:00:20 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 5C8341065670; Tue, 23 Sep 2008 21:00:20 +0000 (UTC) (envelope-from ru@FreeBSD.org) Received: from mail.vega.ru (infra.dev.vega.ru [90.156.167.14]) by mx1.freebsd.org (Postfix) with ESMTP id 14B428FC15; Tue, 23 Sep 2008 21:00:19 +0000 (UTC) (envelope-from ru@FreeBSD.org) Received: from [87.242.97.68] (port=65477 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1KiEK5-000FZg-Hb; Tue, 23 Sep 2008 20:17:25 +0000 Date: Wed, 24 Sep 2008 00:17:18 +0400 From: Ruslan Ermilov To: gnn@freebsd.org Message-ID: <20080923201718.GA88008@edoofus.dev.vega.ru> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Tue, 23 Sep 2008 21:00:20 -0000 Hi, On Tue, Sep 23, 2008 at 03:29:06PM -0400, gnn@freebsd.org wrote: > 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. > > I have tested this in my test lab at work, it is not as yet in > production at my day job, but will be soon. > It's not that bad -- most modern Ethernet drivers initialize interface input queues themselves, and don't depend on IFQ_MAXLEN. The IPv4 input queue is tunable via net.inet.ip.intr_queue_maxlen. The IPv6 queue can similarly be made tunable. I agree that ifqmaxlen can be made tunable because there's still a lot of (mostly for old hardware) drivers that use ifqmaxlen and IFQ_MAXLEN, but I'm against changing the definition of IFQ_MAXLEN. Imagine some code like this: void *x[IFQ_MAXLEN]; // here it's 50 And some function that does: for (i = 0; i < IFQ_MAXLEN; i++) { // not necessarily 50 x[i] = NULL; } Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer