New Firewall (hpf) for DragonFlyBSD

Sebastien Petit spe at selectbourse.net
Sun Jan 11 05:21:59 PST 2004


"Simon 'corecode' Schubert" <corecode at xxxxxxxxxxxx> a écrit dans le message
de news:
>On 10.01.2004, at 15:47, Proceau wrote:
>>> If one wanted to go this way, one could easily use an unsigned char or
>>> short int.
>> With unsigned char one can address that 256 table what is too too
>> little,
>> with shorts int, one can address 65535 table it is more acceptable but
>> that
>> too is can for the large ones numbers rules. That becomes correct
>> starting
>> from 3 bytes, which gives 16 million table, but 3 bytes it is
>> dealigned in
>> the memory, therefore the best choice remains 4 bytes, and which more
>> is
>> that is the fastest solution on the most current architecture.
>> For me 4 octets it"s the big value for lot of rules and the less value
>> for
>> small memory use.
>
> I thought 256 would be enough as the firewall has a binary tree with
> 256 nodes each level.

We can do a base adresse + unsigned int for an index in each node. But
unsigned char and unsigned short is not enough. Eg: in the worse case (no
optimization in the tree), you can have 14 nodes per rule (one per level).
So you can adress nodes for about 20 rules max in the hpf engine that is not
enough.
I can modify the code for letting unchange for IA32 and use the base + index
node technique for architectures > 32 Bits. This is a reasonable way for
supporting all architecture and have maximum performance on Intel 32 Bits
processors.
I must add architecture information (IA32, IA64, sparc etc...) on compiled
rule file header. Then, we avoid the case where someone compile rule file on
IA64 and push it on IA32 architecture (and avoid the reversed byte order
problem).
Can you tell me Simon if there is some defines on dragonfly kernel for
letting know the architecture (like __IA32__,  __IA64__ , __SPARC__,
__SPARC64__ etc...) ?
Forget my "int" questions on the begining of the adress.

Regards,
Sebastien.
--
spe at xxxxxxxxxxxxxxxx







More information about the Submit mailing list