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

Todd Lewis tlewis at ...255...
Fri Apr 6 13:54:08 EDT 2001

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.
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.

Regardless, I just think that snort should be threadsafe and wish the
people who want to work on threading good luck in figuring it all out.

Todd Lewis
tlewis at ...255...

More information about the Snort-devel mailing list