On 11/05/2010 02:16 PM, Mark Martinec wrote:
Jeroen Geilman wrote:
for (entry = list; entry; entry = entry->next) {
Each map is a linked list of CIDR patterns, so consolidate as much as
possible - 10 single IPs will cause noticable delays when the last
entry matches!
Funny c
Jeroen Geilman wrote:
> for (entry = list; entry; entry = entry->next) {
> Each map is a linked list of CIDR patterns, so consolidate as much as
> possible - 10 single IPs will cause noticable delays when the last
> entry matches!
Funny coincidence: just yesterday I added a Patricia (ra
Stan Hoeppner put forth on 11/4/2010 9:20 PM:
> Wietse Venema put forth on 11/4/2010 7:30 PM:
>> Stan Hoeppner:
>>> What's the CIDR lookup table performance difference between say 256 /32
>>> entries and a single /24 entry? Is it 256:1?
>>
>> One /32 match is a probably a little faster than one /
Wietse Venema put forth on 11/4/2010 7:30 PM:
> Stan Hoeppner:
>> What's the CIDR lookup table performance difference between say 256 /32
>> entries and a single /24 entry? Is it 256:1?
>
> One /32 match is a probably a little faster than one /24 match.
> The difference depends on compiler and h
Stan Hoeppner:
> What's the CIDR lookup table performance difference between say 256 /32
> entries and a single /24 entry? Is it 256:1?
One /32 match is a probably a little faster than one /24 match.
The difference depends on compiler and hardware used.
The CIDR implementation could be sped up
On 11/04/2010 11:55 PM, Stan Hoeppner wrote:
What's the CIDR lookup table performance difference between say 256 /32
entries and a single /24 entry? Is it 256:1? Or, how about 90,000 /32
entries vs 60,000 entries that consolidate many of those 90,000 /32s
into larger CIDRs such as /24s and /21s
