ipfw performance and random musings.

[Ian FREISLICH]

Luigi Rizzo wrote:
> On Thu, Aug 24, 2006 at 02:32:04PM +0200, Ian FREISLICH wrote:
> > skipto 1000 ip from any to any ifhash vlan[1000-1264] offset -1000 delta 100
> > 
> > Which for matching interfaces calculates the skipto target as:
> > 
> >     1000 + (iface# + offset) * delta
> > 
> > If you're happy with this format, I'll update the ipfw manual page
> > and submit a patch for review and commit.
> 
> I would suggest a modification to the syntax as follows:
> 
>         skipto @        ...   recv|xmit|via foo[A-B] base X delta D
.................................................^^^^^

This will then conflict with:

ip_fw2.c iface_match():

        if (cmd->name[0] != '\0') { /* match by name */
                /* Check name */
                if (cmd->p.glob) {
                        if (fnmatch(cmd->name, ifp->if_xname, 0) == 0)
                                return(1);

cmd->p.glob as set up by ipfw2.c fill_iface():

      else if (!isdigit(*arg)) {
                strlcpy(cmd->name, arg, sizeof(cmd->name));
                cmd->p.glob = strpbrk(arg, "*?[") != NULL ? 1 : 0;

> where @ is a keyword (meaning "the jump target is computed elsewhere")
> and "foo[A-B] base X delta D" is an extension of the interface-name
> option already available in ipfw.

I also don't like 'skipto @' because that complicates the skipto
syntax.  I'd prefer to keep skipto the same and use a rule option
to modify the skipto target.  I'm also not overly enthused with
putting this data into the ipfw_insn_if type.

I'm happy to compromise since I think what's confusing the issue
is this feature is really both a rule action and body and not just
a rule body.  Perhaps this is better:

skipto 1000 delta 100 ip from any to any via vlan1002-vlan1264

This then extends the recv|xmit|via syntax to allow "ranges" of
like interfaces and the skipto syntax to calculate offsets.  "delta"
being optional and defaulting to zero and implying a value based
on the interface number.

> The motivations are the following:
> 1. "ifhash" is misleading, as it isn't really hashing anything.

That occured to me.  You suggested "ifhash" though :)

>    The real hashing, if you implemented it, is in the 
>    rule_number --> rule_ptr lookup table, which is a general mechanism 
>    and not a specific one.

I did.  But reading my thread in -CURRENT about vlan performance
it appears there might heavy objection to this since it costs 256k
of memory, ond they're fighting over 16k to get a ~8% performance
boost with CPU utilisation down from 75% to 3%.

> I have no idea how you wrote your current implementation but i
> believe that by using the above syntax even the internal implementation
> could be quite straightforward.

Are you a context or unified diff man?

Ian

--
Ian Freislich