Re: packet forwarding/firewall performance question

From: Ian FREISLICH <ianf_at_clue.co.za>
Date: Tue, 18 Aug 2009 12:57:59 +0200
Robert Watson wrote:
> 
> On Thu, 13 Aug 2009, Tom Uffner wrote:
> 
> > i'm hoping a few people will give me estimates on what kind of
> > throughput i should theoretically expect before i provide any actual
> > test data. also, any suggestions on tuning would be welcome.
> >
> > so far in preliminary tests, enabling polling on the network
> > interfaces reduces my performance slightly both to/from and through
> > the box. net.inet.ip.fastforwarding doesn't seem to make much
> > difference either way but i haven't done very thorough testing of
> > it. increasing net.inet.tcp.sendbuf_max & recvbuf_max may have
> > helped, but again, not sufficiently tested.
>
> I can't speak to absolute numbers, but I wouldn't expect
> net.inet.tcp.* changes to make any difference, as they should affect
> only locally terminated sockets on the firewall host, not forwarded
> packets.
>
> You might want to try experimenting with net.isr.direct -- try setting
> it to 0, as this changes the kernel dispatch model for the network
> stack.  On a UP box, I would probably anticipate a performance loss
> for making that change, or similar configuration changes for multiple
> netisr threads using net.isr.maxthreads.
>
> If you're using firewall code, fast forwarding is unlikely
> to make a difference.  Depending on the cache/memory/CPU
> trade-off, you might find turning off flowtable support helps --
> net.inet.flowtable.enable=0.

I found that forwarding made a fantastic difference to the forwarding
rate in the past.  Even with firewalling - was the difference between
38kpps and 500kpps using RTL8110 gigE interfaces.  Perhaps I need
to retest the effect on a modern FreeBSD.

As to the OP, on a VIA Epia LN - C7-1GHz with vr interfaces maxed
out at 100Mbit/s.  Putting gigE interfaces in the PCI slot made no
difference.  The bottle-neck appeared to be the number of interrupts
the cards generated and the amount of time servicing interrupts,
which was not affected by polling(4).

Ian

--
Ian Freislich
Received on Tue Aug 18 2009 - 08:57:54 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:54 UTC