Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate

Hi Julian Elischer!

On Wed, 26 Mar 2008 10:31:12 -0700; Julian Elischer wrote about 'Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate':

here are some of my ideas for ipfw changes:

1/ redo locking so that packets do not have to get locks on the
structure... I have several ideas on this

Currently the main need for locking arises for rule byte/packet counters. The
easiest short-term solution
The main need for locking is that the rules can be changed while a
processor is traversing the rule set.

Oh, I haven't finished the letter. I wanted to say that easiest short-term
solution would be splitting main ruleset lock into 2 locks: one for ruleset and
one for counters, and wrap the only "f->*cnt +=" with that locks.

2/ allow separate firewalls to be used at different parts of the
network stack (i.e allow multiple taboe sto co-exist)
there are many places that ipfw is currently callable from.
ip_input(), ip_output(), ether_demux(), if_brige, ether_output()

it would be interesting tobe able to have differnt firewalls in these
places (possibly per interface) so that state (e.g. keep_state)
can be kept seprately for one place then from another.

for example you may not want the result of 'keep state' on an
external interface to necessarily affect what happens to
packets from the same session when viewed traversing an internal
interface.

Currently on my more complex ipfw rule sets I break the rule sets out
so that packets in different places traverse different rules
but it would be nice to have it explicitly supported.

Good. That should be added to proposal in part of creation of dynamic rules in
any state: by default all-shared dynamic rules should be used (to preserve POLA),
and an option in rule can be specified for a specific pass/layer.

Umm, could you explain it a little?..

3/ possibly keeping per CPU stats..

How that would be represented to user?
it wouldn't.. you'd add them together before presenting them.
but every time a packet changes a counter that is shared, there is a
chance that it is being altered by another processor, so if you have
fine grained locking in ipfw, you really should use atomic adds,
which are slow, or accept possibl collisions (which might be ok)
but still cause a lot of cross cpu TLB flushing.

Looked at the code... oh... I was wrong above with splitting for two locks into
second for counters. It merely doen't exist and counters can get corrupted just
now :-) The idea to keep separate per-CPU counters *could* be just reasonable,
but as O_COUNTERLIMIT is likely to be introduced, it will need to access to
already combined values, which now can be just for every packet, thus
invalidating whole idea.

The possible solution can again lie in ruleset compiled to single area of
opcodes rather than linked list. In this case counters can be made a separate
from opcodes array of int64's which will be contiguous and much smaller than
current opcodes/counters mix, so chances for cache misses/flushes will be much
smaller too.

--
WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@xxxxxxx
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]

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

Relevant Pages

  • Re: Does query optimizer use locking hints?
    ... I am not aware of any simple way to see the locking impact. ... In Profiler, one of the counters is elapsed time. ...
    (microsoft.public.sqlserver.programming)
  • Re: display an alert only once
    ... I would keep counters in a database. ... mycounter = mycounter+1" and the database should do all the locking ... Hans Kesting ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49
    ... because the thing you race with is not the "return to user space" ... And those incoming packets might have been incoming before the rules were ... of various counters -- there are a number of Linux networking users who ... 32-bit UP machines and 64-bit machines are not ...
    (Linux-Kernel)
  • Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49
    ... because the thing you race with is not the "return to user space" ... And those incoming packets might have been incoming before the rules were ... of various counters -- there are a number of Linux networking users who ... 32-bit UP machines and 64-bit machines are not ...
    (Linux-Kernel)
  • Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49
    ... because the thing you race with is not the "return to user space" ... And those incoming packets might have been incoming before the rules were ... of various counters -- there are a number of Linux networking users who ... 32-bit UP machines and 64-bit machines are not ...
    (Linux-Kernel)