Re: IPFW update frequency

Luigi Rizzo wrote:
On Fri, Mar 30, 2007 at 01:40:46PM -0700, Julian Elischer wrote:
I have been looking at the IPFW code recently, especially with respect to locking.
There are some things that could be done to improve IPFW's behaviour when processing packets, but some of these take a
toll (there is always a toll) on the 'updating' side of things.

certainly ipfw was not designed with SMP in mind. If you can tell us what is your plan to make the list lock free
(which one, the static or dynamic ones ?) maybe we can comment more.

E.g. one option could be the usual trick of adding refcounts to
the individual rules, and then using an array of pointers to them.
While processing you grab a refcount to the array, and release it once
done with the packet. If there is an addition or removal, you duplicate
the array (which may be expensive for the large 20k rules mentioned),
manipulate the copy and then atomically swap the pointers to the head.

This is pretty close.. I know I've mentioned this to people several times over
the last year or so. the trick is to try do it in a way that the average packet
doesn't need to do any locks to get in and the updater does more work.
if you are willing to acquire a lock on both starting and ending
the run through the firewall it is easy.
(I already have code to do that..)
(see http://www.freebsd.org/~julian/atomic_replace.c (untested but
probably close.)
doing it without requiring that each packet get those locks however is a whole new level of problem.


This might even work for dynamic rules as the lists (the content of
each hash bucket) are typically short.

yep


cheers
luigi

_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: IPFW update frequency
    ... Luigi Rizzo wrote: ... Your tests presumably have little if any contention on the lock. ... main rule loop of ipfw to speed things up. ... last year with an Agilent packet generator and hwpmc. ...
    (freebsd-net)
  • Re: IPFW update frequency
    ... There are some things that could be done to improve IPFW's behaviour when processing packets, but some of these take a ... certainly ipfw was not designed with SMP in mind. ... If you can tell us what is your plan to make the list lock free ... done with the packet. ...
    (freebsd-net)
  • FreeBSD 5.3 Bridge performance take II
    ... I have just finished some profiling and analysis of the FREEBSD_5_BP code ... factor seems to be simply the number of mutexes (11 per packet ... uma_zalloc_arg (per CPU lock) ... Implement device level caching for the UMA mbuf zones. ...
    (freebsd-current)
  • FreeBSD 5.3 Bridge performance take II
    ... I have just finished some profiling and analysis of the FREEBSD_5_BP code ... factor seems to be simply the number of mutexes (11 per packet ... uma_zalloc_arg (per CPU lock) ... Implement device level caching for the UMA mbuf zones. ...
    (freebsd-current)
  • Re: IPFW update frequency
    ... Your tests presumably have little if any contention on the lock. ... the lock acquisition cost is in the 'setup' part but i cannot tell ... main rule loop of ipfw to speed things up. ... last year with an Agilent packet generator and hwpmc. ...
    (freebsd-net)