Date: Wed, 24 Sep 2008 15:42:42 -0400 From: gnn@FreeBSD.org To: "Bruce M. Simpson" <bms@FreeBSD.org> Cc: net@FreeBSD.org Subject: Re: Proposed patch, convert IFQ_MAXLEN to kernel tunable... Message-ID: <m2skrp5o0d.wl%gnn@neville-neil.com> In-Reply-To: <48DA53B8.3030407@FreeBSD.org> References: <m2skrq7jb1.wl%gnn@neville-neil.com> <48DA53B8.3030407@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At Wed, 24 Sep 2008 15:50:32 +0100, Bruce M. Simpson wrote: > > 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. > Actually what we'd need is N of these, since my target is actually the send queue, not the input queue. Let me look at this some more. Best, George
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m2skrp5o0d.wl%gnn>