Making IFQ_MAXLEN tunable
Bjoern A. Zeeb
bzeeb-lists at lists.zabbadoz.net
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:
>>> 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