cvs commit: src/sys/netgraph/netflow ng_netflow.c

[Gleb Smirnoff]

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