[Snort-devel] RE: A Proposal for Reengineering Snort's Packet Matching System - Comments

Fyodor fygrave at ...1...
Fri Apr 6 14:02:32 EDT 2001

On Fri, Apr 06, 2001 at 01:54:08PM -0400, Todd Lewis wrote:
> On Sat, 7 Apr 2001, Fyodor wrote:
> > I'd rather make parallel threads/processes for every task which snort
> > is doing.. i.g.  packet capture - packet decoding - detection engine -
> > logging, all these routines could be papelined to increase productivity
> > (IMHO), alternatively you could parallelize things per-packet but will
> > it really scale well?
> One question is, what are you trying to minimize.  Do you want to minimize
> memory access contention, in which case you take Fyodor's approach,
> or do you want to minimize copying costs associated with sending a
> packet around, in which case you implement Abe's threadpool suggestion.

IMHO the right way to figure out the solution for this problem is to do
snort profiling and see which parts utilize more cpu (anyone got any experience
with that), so we could where do we spend more resources and could try to 
design parallel execution so similary 'loaded' parts could balance  each 

> I would lean towards a threadpool, not because it's necessarily cheaper,
> but because the differences in the workload among the various stages
> will be considerable, so you'll have your post-processing thread idle
> while your rule-matching thread is thrashing, or vice-versa.  Even if
> a threadpool is a tad less efficient, it will make up for it by being
> able to use all available CPU resources.

Ah.. I still need to have a look into Abe's suggestion in more details (reading my mail
in backwards order, as usual :))

> Regardless, I just think that snort should be threadsafe and wish the

Right. That definetely is the case :)

More information about the Snort-devel mailing list