Making IFQ_MAXLEN tunable

Bjoern A. Zeeb bzeeb-lists at
Sat May 1 09:20:08 UTC 2010

On Fri, 30 Apr 2010, Maxim Sobolev wrote:


> Julian Elischer wrote:
>> On 4/30/10 1:23 PM, Maxim Sobolev wrote:
>>> Hi,
>>> Many network drivers in the FreeBSD kernel use the IFQ_MAXLEN value to
>>> set length of the outgoing packets queue. The default value for that
>>> parameter is only 50, which is pretty low especially for the cases when
>>> the system handles lot of small packets and can cause ENOBUFS in
>>> applications under the load. The following patch makes IFQ_MAXLEN a
>>> tunable. I am also tempted to bump the default value for IFQ_MAXLEN
>>> 10-fold, but would like to hear what do people think about it first.
>> so just tunable? not a sysctl :-)
> The sysctl would require much bigger rewrite. As long as I understand the 
> value is now cached in many instances of the ifnet structure, and some 
> drivers even use their own queue length instead of IFQ_MAXLEN. Therefore, 
> even if I make this parameter a sysctl one would have to destroy interface 
> and create it again in order for the change to have an effect. Therefore, 
> keeping it tunable would be less confusing.
>> patch could be a lot smaller if you defined IFQ_MAXLEN to be V_ifqmaxlen 
>> (do different vimages want a different value?)
> I am not quite sure about that. AFAIK vimage is more high-level thing, while 
> this parameter controls queue length between kernel and hardware interface 
> driver. vimage lies above that.

My leaning goes that it should be a global system boottime configuration and
neither a sysctl nor a value per virtual network stack.
If we'd want it to be anything else, like making a sysctl I'd prefer
to have it global rather than having someone inside a virtual network
stack as it basically restricts the usage of global resources (mbufs).
If we can get it a sysctl and will have resources limits it will be
easily converted into a per-vnet configuration.


Bjoern A. Zeeb                                   See you when I see you.

More information about the freebsd-current mailing list