From owner-cvs-src@FreeBSD.ORG Thu Feb 7 10:16:17 2008 Return-Path: Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9223416A591; Thu, 7 Feb 2008 10:16:17 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.130]) by mx1.freebsd.org (Postfix) with ESMTP id 952CB13C502; Thu, 7 Feb 2008 10:16:16 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.1/8.14.1) with ESMTP id m17AGJDq075984; Thu, 7 Feb 2008 13:16:19 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.1/8.14.1/Submit) id m17AGJNm075983; Thu, 7 Feb 2008 13:16:19 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 7 Feb 2008 13:16:19 +0300 From: Gleb Smirnoff To: Louis Mamakos Message-ID: <20080207101619.GH14339@FreeBSD.org> References: <200801271501.m0RF1Hki089075@repoman.freebsd.org> <20080202201153.GL14339@FreeBSD.org> <47A4E122.8080901@FreeBSD.org> <20080205141739.GX14339@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15 (2007-04-06) Cc: cvs-src@FreeBSD.org, Alexander Motin , src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netgraph/netflow ng_netflow.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2008 10:16:17 -0000 On Wed, Feb 06, 2008 at 10:59:32PM -0500, Louis Mamakos wrote: L> I suppose the problem is that I had no expectation that a kernel module, L> would L> consume unbounded amounts of kernel resources. It is bounded. L> I certainly didn't expect L> that L> it would have a need to store "a lot of data" given that there are L> documented L> parameters on how the in-kernel state should be expired. That this L> expiration L> doesn't occur is a significant difference that would I would have expected L> as L> reasonable behavior. This is behavior of not yet configured node. Imagine yourself adding a new log destination to syslog.conf(5), but forgetting about newsyslog.conf(5). Are you going to file a PR "FreeBSD wastes all my disk space"? No. Same situation here - you have configured the flow of incoming data, but you haven't configured the destination of the outgoing data. L> You start with the presumption that the data being collected is so precious L> that L> it cannot be dropped under any circumstances. That's probably a faulty L> premise to begin with, given that most of the netflow export happens on an L> unreliable UDP transport. Well, the ng_netflow(4) node has nothing to do with UDP. You can put any alternative transport on the "export" hook. L> > I agree that the behavior should be documented in manual page and using L> > ng_hole(4) for your case should be advised. If you send me a manual page L> > patch, L> > I can commit it. L> L> Driving the kernel into resource exhaustion for no really good reason L> doesn't L> seem like the right default behavior. I really think that the netflow L> module should default into a safe mode of operation rather than unexpected L> consumption of a limited resource. See above. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE