On Fri, 30 Apr 2010, Maxim Sobolev wrote: Hi, > 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. >>> >>> http://sobomax.sippysoft.com/IFQ_MAXLEN.diff >> >> 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. /bz -- Bjoern A. Zeeb See you when I see you.Received on Sat May 01 2010 - 07:20:08 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:03 UTC