Network performance in a dual CPU system

[Andre Oppermann]

Max Laier wrote:
> 
> On Friday 10 February 2006 20:54, Julian Elischer wrote:
> > Marcos Bedinelli wrote:
> > > Hello all,
> > >
> > > thanks for the replies. Most of you have suggested that I turn on
> > > polling and give it a try. The machine is in production, hence I need
> > > to schedule downtime for that.
> > >
> > > The system is mainly being used as a dedicated router. It runs OSPF,
> > > BGP and IPFW (around 150 rules). OSPF and BGP are managed by Quagga.
> > > The box has 2 gigabit interfaces that handle on average 200Mbp/s - 50K
> > > packets/s (inbound and outbound combined), each one of them.
> >
> > I have found that most people can optimise there ipfw rulests considerably.
> >
> > for example: a first rule of:
> > 1 allow ip from any to any in recv {inside interfacfe}
> > 2 allow ip from any to any out xmit {inside interface}
> > will cut your ipfw load by 50% immediatly.
> > (you should only be filterring on one interface usually)
> >
> > use 'skipto' rules to immediatly send incoming and outgoing data to
> > different rules sets.
> 
> FWIW, pf does some of those optimizations automatically called "skip steps"
> and "pfctl -o" restructures the ruleset so that often matching rules are
> moved to the top.  I know that this does not map directly to IPFW, but it
> might still be interesting to have a look at it.

>From my profiling with the Agilent tester there seem to be two areas where
the packet filters (ipfw in my test case) burn a lot of CPU per packet.
That is a) setup of lots of packet variables unconditionally at the entry
of ip_fw_chk() no matter whether they get looked at later or not, and b)
the switch() going through all the packet inspection options is for some
reason not optimized by the compiler and burns even more CPU.  Some sort
of JIT (as in the new bpf code) which replaces the case testing and jumps
directly to the proper place in the switch statement would go a long way
of making it way more performant.

-- 
Andre