Re: New Target: ipt_ACCOUNT

[Harald Welte <laforge@gnumonks.org>]

[-- Attachment #1: Type: text/plain, Size: 3641 bytes --]

On Mon, Jan 06, 2003 at 06:22:48PM +0100, Rolf Wuerdemann wrote:

> Hi Harald (hope first name is o.k. ;) - no prob ;)

Klar doch.

> >  I think this is the wrong approach, there are way too much data
> > strucctures in non-swappable kernel momory allocated.  And kernel-OOM is
> > not something we should provoke.  A better architecture from my point of
> > view was: - use ULOG to copy the IP+TCP header of all packets to
> > userspace [it is very efficient in doing so!!!] and then do all the
> > accounting in userspace
> 
> I was aware of the OOM-Problem (so DDoS can kill your Router!), and thought
> about something like acctrack_max (simmilar to contrack_max) so you can
> set an maximum of tracked connections. This is not an solve for the root 
> of the problem (to much data structures) - but an solve if you're afraid of
> running OOM from this side. - 

> Perhaps I'll do some tests using ULOG, but
> from work with nacctd I know that copying packets from Kernel to User-Space
> takes much time (and time/speed was something I want to save ;)

Don't even start to compare the two.  The method used is totally
different.  With ULOG you can have a in-kernel buffer of let's say 64k
and fill this buffer with the first 40 bytes per packet.  Then if 1638
packets have accumulated, the buffer is flushed via a netlink socket.
Several optimizations compared to a packet socket (what tcpdump does)
	- you only copy the header of the packets (if you want)
	- you have way less kernel/userspace transitions (and thus
	  context switches) because of the buffered concept
	- you filter the packets before you send them to userspace
	  as opposed to dumping everything and then 

I have reports from people who are dumping 100MBit under full load to
userspace on 400-500MHz boxes from more than a year ago.

I'd love if you would give it a try, although it would mean developing
yet another implementation of what you have already working ;)

> *G* - no problem to fix (like some debug-messages, etc ;) - I've posted
> the source before "cleanup" - so I can work in suggestions/comments with
> the cleanup ;) 

Ok, great. Thanks for taking care.


> > - the kernel/userspace interface using a socket option
> 
> Yes - thinking about using /dev/accouning (fs i/o) to get the
> data from kernel-space - /proc-fs seems to be unlikely (approx 2M
> filesize) - any opinions?

Well, I haven't suggested an alternative because I didn't have one which
was looking better than the socket option...

This is a generic problem for everything (like ippool, the condition
match, ...) inside netfilter/iptables that wants to transport some data
from kernel to userspace.

> Nothing to sorry ;) - Hwo should I post the changed version? Complete,
> diff, link to ftp/cvs?

maybe post one more version, then convert it to patch-o-matic and submit
a patch against recent CVS.

> Hmmm ... If you want to gain speed it's one of the best solutions - account 
> the packets at the lowest possible level ;)

Yes. But then why do we use a multi purpose, multi user, multi tasking
operating system instead of a realtime OS?

Either we do want high efficiency and compromise security, layering,
etc. - or we want security, layering, abstraction... and will loose some
performance.

> Regard's

-- 
- Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
============================================================================
"If this were a dictatorship, it'd be a heck of a lot easier, just so long
 as I'm the dictator."  --  George W. Bush Dec 18, 2000

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]