From owner-svn-src-all@FreeBSD.ORG Mon Aug 19 21:08:11 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 7E75D3A1 for ; Mon, 19 Aug 2013 21:08:11 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E585828D3 for ; Mon, 19 Aug 2013 21:08:10 +0000 (UTC) Received: (qmail 76569 invoked from network); 19 Aug 2013 21:51:34 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 19 Aug 2013 21:51:34 -0000 Message-ID: <52128937.1010407@freebsd.org> Date: Mon, 19 Aug 2013 23:08:07 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Peter Grehan Subject: Re: svn commit: r254520 - in head/sys: kern sys References: <201308191116.r7JBGsc6065793@svn.freebsd.org> <521256CE.6070706@FreeBSD.org> <5212587A.2080202@freebsd.org> In-Reply-To: <5212587A.2080202@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 21:08:11 -0000 On 19.08.2013 19:40, Peter Grehan wrote: >> 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. I'm sorry for ambushing but this stuff has to be done. I have provided an alternative way of handling it and I'm happy to help you with your use case to make it good for you and to prevent the mbuf system from getting bloated and hackish again. Mbuf is a core system for the kernel and we should avoid to kitchen-sink it again while at the same time to keep speedy enough to keep up with the speed requirements. I believe it would be bad to have Navdeep, you and others invent their own network buffer management routines over again in slightly different ways tailored to each immediate use case. Can you please describe your intended use of M_NOFREE to better understand the shortcomings of the current mbuf systems and the additional advantages of the M_NOFREE case? -- Andre