From owner-svn-src-all@FreeBSD.ORG Mon Aug 19 17:40:16 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 097EEAA9; Mon, 19 Aug 2013 17:40:16 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id BD0972D45; Mon, 19 Aug 2013 17:40:15 +0000 (UTC) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTPS id E633012373; Tue, 20 Aug 2013 03:40:13 +1000 (EST) Received: from Peter-Grehans-MacBook-Pro-2.local (c-69-181-164-196.hsd1.ca.comcast.net [69.181.164.196]) by dommail.onthenet.com.au (MOS 4.2.4-GA) with ESMTP id BOB56127 (AUTH peterg@ptree32.com.au); Tue, 20 Aug 2013 03:40:12 +1000 Message-ID: <5212587A.2080202@freebsd.org> Date: Mon, 19 Aug 2013 10:40:10 -0700 From: Peter Grehan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: svn commit: r254520 - in head/sys: kern sys References: <201308191116.r7JBGsc6065793@svn.freebsd.org> <521256CE.6070706@FreeBSD.org> In-Reply-To: <521256CE.6070706@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Navdeep Parhar X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 17:40:16 -0000 > I recently tried some experiments to reduce the number of mbuf and > cluster allocations in a 40G NIC driver. M_NOFREE and EXT_EXTREF proved > very useful and the code changes to the kernel were minimal. See > user/np/cxl_tuning. The experiment was quite successful and I was > planning to bring in most of those changes to HEAD. I was hoping to get > some runtime mileage on the approach in general before tweaking the > ctors/dtors for jumpbo, jumbo9, jumbo16 to allow for an mbuf+refcnt > within the cluster. But now M_NOFREE has vanished without a warning... I also had a virtualization work-in-progress where static mbufs were allocated in the kernel and M_NOFREE set. Might be worth sending a prior heads-up for these type of changes. later, Peter.