From owner-freebsd-net@FreeBSD.ORG Wed Oct 13 17:46:59 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96A19106564A; Wed, 13 Oct 2010 17:46:59 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7761B8FC14; Wed, 13 Oct 2010 17:46:57 +0000 (UTC) Received: by ewy21 with SMTP id 21so1150113ewy.13 for ; Wed, 13 Oct 2010 10:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=cVl9GYqaUJV/6wjFPm3t4KlO0pGyRLXf0fnJfrWB8QU=; b=pbjYfqg8LFKmYI2unYAO/8WAzcvFU217eRVZtUyZs2SJv/KmLWOBnaBcy1htEClx6u iwrnjhQXZ2eSFB//pQUEn6Sgg7qOHhsK9rGw7Bh52KSUD0v+7syJ7rEX88xZBWyyRL/O 6O16VncF9MrQ3fQC5iH/esNH+t4IQTCbdE/H0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uXY70TAS9Te13E/4zRMWkiC82CF9vkDz5awIvSTc3KsX2p6u6vYhifG0yb+6q3wIZ5 E6JNWtrs17RMuyNpGBkKl+1wlAwZ6KsSWxd1tHppGma1Sbkqbux377qJ5vhwoha1EbW2 Sp20bzZtJ5GdX536BDLIHYiQghRuB45zKKJPs= MIME-Version: 1.0 Received: by 10.213.27.135 with SMTP id i7mr902554ebc.29.1286992016979; Wed, 13 Oct 2010 10:46:56 -0700 (PDT) Received: by 10.213.105.208 with HTTP; Wed, 13 Oct 2010 10:46:56 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Oct 2010 13:46:56 -0400 Message-ID: From: Ryan Stone To: Robert Watson Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current , freebsd-net@freebsd.org, Attilio Rao , Sergey Kandaurov , Jack F Vogel , Ryan Stone , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 17:46:59 -0000 On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson wrote: > + /* > + * get and fill a header mbuf, then chain data as an > extended > + * mbuf. > + */ > + MGETHDR(m, M_DONTWAIT, MT_DATA); > > The idea of calling into the mbuf allocator in this context is just freaky, > and may have some truly awful side effects. I suppose this is the cost of > trying to combine code paths in the network device driver rather than have > an independent path in the netdump case, but it's quite unfortunate and will > significantly reduce the robustness of netdumps in the face of, for example, > mbuf starvation. Changing this will require very invasive changes to the network drivers. I know that the Intel drivers allocate their own mbufs for their receive rings and I imagine that all other drivers have to do something similar. Plus the drivers are responsible for freeing mbufs after they have been transmitted. It seems to me that the cost of making significant changes to the network drivers to support an alternate lifecycle for netdump mbufs far outweighs the cost of losing a couple of kernel dumps in extreme circumstances.