Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Sep 2008 00:17:18 +0400
From:      Ruslan Ermilov <ru@FreeBSD.org>
To:        gnn@freebsd.org
Cc:        net@freebsd.org
Subject:   Re: Proposed patch, convert IFQ_MAXLEN to kernel tunable...
Message-ID:  <20080923201718.GA88008@edoofus.dev.vega.ru>
In-Reply-To: <m2skrq7jb1.wl%gnn@neville-neil.com>
References:  <m2skrq7jb1.wl%gnn@neville-neil.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080923201718.GA88008>