ipfw performance and random musings.

[Luigi Rizzo]

trimming the thing...

On Fri, Aug 25, 2006 at 01:41:03PM +0200, Ian FREISLICH wrote:
...
> > the problem i see above is that the 'delta' is really an attribute
> > of the 'vlanA-B' instruction.
> > Say you have this rule:
> > 
> > 	skipto 1000 recv vlan1002-vlan1264
> > 
> > does it mean 'skip to 1000 plus the interface number' or
> > 'skip to 1000 unconditionally' (i suppose the former because
> 
> This means skipto 1000 if the interface is in the range since delta
> defaults to zero.

which proves my point - this is hidden information which you happen to
know but it is not obvious, whereas an explicit difference in the
syntax makes it clear.

> > otherwise the 'skipto' would have two different meanings
> > depending on whether or not there is a subsequent vlanA-B specifier) ?
> 
> No, it is the delta option to skipto that determines whether the
> target is calculated or not.  Actually it's always calculated from

again: the target is calculated using the start-of-range which
is in the ifname* option. If you don't pack all the info
(base+delta) in the if_name instruction, you have to lookup
the 'skipto' instruction in order to do the computation.
Conversely, if you just support a generic 'indirect skipto',
you do the computation in the if_name (or other instruction),
store the result in a well-known place (basically a variable
in the function) and then when/if you find the skipto you
use the value from there.

> So my current thinking is to extend the recv,xmit,via syntax to use
> a range, so that you can do:
> 
> deny udp from any to any via re0-re5
> fwd 127.0.0.1:3182 tcp from any to any 80 in recv fxp3-fxp7

i am basically ok with this except, as i said, that there is
no point in replicating the interface name i.e. why re0-re5
instead of just re0-5 ? you just open up to possible mistakes
and the need for extra code to check what happens when the user
types re2-de5 (by mistake or intentionally).

> > if you make it a hash table you don't have to worry about static sizes,
> > and it also removes the multiple number -> pointer entries that are
> > embedded in the rules (mostly important from an update-cost point of view).
> 
> Except that you see how badly the hash affects CPU utilisation in the
> case of the vlan driver: hash - 75% CPU, lookup table - 3% CPU at

that might depend on a poor match between the hash table size and
the actual data set, or an expensive hash function.
That's a huge difference that cannot be explained otherwise. 

> In private mail.

ok thanks.

luigi