Proposed patch, convert IFQ_MAXLEN to kernel tunable...

[gnn at FreeBSD.org]

At Wed, 24 Sep 2008 00:17:18 +0400,
Ruslan Ermilov wrote:
> 
> Hi,
> 
> On Tue, Sep 23, 2008 at 03:29:06PM -0400, gnn at 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:
> 

Sorry, this is about the output queue, not the input queue.

Though there are both input and output queues that depend on 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;
> }
> 

I found no occurrences of the above in our code base.  I used cscope
to search all of src/sys.  Are you aware of any occurrences of this?

Best,
George