At Wed, 24 Sep 2008 00:17:18 +0400, Ruslan Ermilov wrote: > > Hi, > > On Tue, Sep 23, 2008 at 03:29:06PM -0400, [EMAIL PROTECTED] 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 _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"