[Snort-devel] snort-2.0 and paengines

Dragos Ruiu dr at ...40...
Thu Jan 18 22:29:20 EST 2001

On Thu, 18 Jan 2001, Martin Roesch wrote:

> > 7) I notice that the present threading code assigns one thread per
> > interface.  I am curious as to why you could not just run one instance
> > of snort per interface instead.  Wouldn't the performance be the same?
> > If I do take over the threading stuff, my disposition would be to move
> > away from this model to a worker-pool model, where worker threads queue
> > up to receive the next available packet from the paengine, serialized
> > by a mutex; this would spread the workload even via packet acquisition
> > mechanisms with a single entry point, like netfilter.  Would there be
> > any objections to this approach?
> So you're proposing having one thread per packet and handling packet
> asynchronously?  That could present certain complications with things
> that expect to see them in a synchronous fashion (defrag, stream, etc). 
> What about threading the output stage?  Having the output section of
> Snort be "non-blocking" (not really, but you know what I mean) would be
> really nice, especially when we're doing slow DB inserts.

I've thought about how to parallelize the defragging and reassembly, and
to make a long story short, imho it would likely take a bunch of code to manage
the threads and dole (partition them into unconnected/unsynchronized data
pools) out the packets to separate threads (where each has isolated data).  But
right now it's unclear what exactly this would buy other than some additonal
work and a slowdown. A medium term option is to have a single defragger
thread and each stream reassembly run in separate threads and feed the
appropriate packets to the threads while another set of threads runs for other
non-fragmented, non-reassembled packets.

But let me chorus that I also agree with Marty that there should be no
uniprocessor performance hit for the threading... at least until we start to
really need smp ooph because we are running out of CPU badly on conventional
hardware (which I don't think we are at yet).  There are probably a lot of
other things that we need to need to do before threading, but that being said
it's always nice to keep an eye open to the future so we don't shoot ourselves
in the foot / paint ourselves into a corner when we may get to needing to make
some changes in some direction (can anyone say gcc :-).


Dragos Ruiu <dr at ...9...>   dursec.com ltd. / kyx.net - we're from the future 
gpg/pgp key on file at wwwkeys.pgp.net

More information about the Snort-devel mailing list