From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 22:00:12 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EE913106566B; Fri, 30 Apr 2010 22:00:11 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id A90028FC15; Fri, 30 Apr 2010 22:00:11 +0000 (UTC) Received: from [192.168.1.38] (S0106005004e13421.vs.shawcable.net [70.71.175.212]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id o3UM08Ib094512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Apr 2010 15:00:09 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <4BDB52F4.2010100@FreeBSD.org> Date: Fri, 30 Apr 2010 15:00:20 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Julian Elischer References: <4BDB3C31.4050709@sippysoft.com> <4BDB4CAE.20006@elischer.org> In-Reply-To: <4BDB4CAE.20006@elischer.org> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, "current@freebsd.org" Subject: Re: Making IFQ_MAXLEN tunable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 22:00:12 -0000 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. -Maxim