[Snort-devel] I think I got it

Phil Wood cpw at ...86...
Tue Jul 31 01:38:18 EDT 2001


On Mon, Jul 30, 2001 at 11:52:36PM -0400, tlewis at ...255... wrote:
> On Mon, 30 Jul 2001, Phil Wood wrote:
> 
> > I believe that you could get away with creating the necessary storage
> > either statically, or when called as local arrays.  I would pick which
> > ever method caused the least number of cycles.  I like static, cause
> > memory is cheap and you formalize the use and can't interfer with other
> > routines.  I think that would cut down on alot of malloc / free subroutine
> > calls.
> 
> I disagree; statics lead to non-thread-safe code.  It's cycles that
> are free on today's memory-latency-constrained systems, and trading more
> computation for less memory access and paying attention to memory topology
> (can my structures fit in a single cache line?  do they?)  will pay many
> more dividends than trying to cut back artiicially on number allocations.

I'll defer to your analysis.  I cut my eye teeth on 64K byte machines
like the SDS 940's (not Students for a Democratic Society) using Brandt
discs the housing of which was about the size of two large ice boxes.
What's amazing is how well it performed as a time-sharing machine back in
the late 60's.

Now if I can just find what piece of snort code stored a small
number in a memory location malloc's for a structure pointer.  It's never
the same number, but it's always in the first fragment retrieved from 
one of those fancy lists used by frag2.  And it's not the initial fragment,
or the last.  Not that there is a problem with that in principal, but
it seems to be the one constant for each of the latest seg faults.

Thanks,

I needed that.  %^)

> 
> Of course, the huge speedups to be had are in packet acquisition, not
> in matching and processing, but no one seems interested in working on
> that area...
> 
> --
> Todd Lewis
> tlewis at ...255...

-- 
Phil Wood, cpw at ...86...





More information about the Snort-devel mailing list