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

Vadim Goncharov wrote:
Hi Julian Elischer!

On Mon, 24 Mar 2008 10:53:44 -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.


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.


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.



_______________________________________________
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

  • tcp hostcache and ip fastforward for review
    ... this patch contains three things (to be separated for committing): ... - removes ip route cache in ip_input.c (locking much easier) ... - removes most (tcp specific) metrics from rtentry metrics ... - fixes wrong goto in tcp_input.c which sends two RST packets ...
    (freebsd-net)
  • tcp hostcache and ip fastforward for review
    ... this patch contains three things (to be separated for committing): ... - removes ip route cache in ip_input.c (locking much easier) ... - removes most (tcp specific) metrics from rtentry metrics ... - fixes wrong goto in tcp_input.c which sends two RST packets ...
    (freebsd-current)
  • Re: [RFC 0/2] new kfifo API
    ... and I disagree about the locking changes. ... Except for Andi's NMI driver, ... Changing the behaviour of an existing interface without changing ... but the first patch will break something. ...
    (Linux-Kernel)
  • Re: [RFC 0/2] new kfifo API
    ... Stefani Seibold wrote: ... About the locking stuff, I think it should best be left in place. ... interface work in an entirely safe way (kfifo_get doing all the ... If you have fixed records, I would guess that you always need it ...
    (Linux-Kernel)
  • Re: [RFC 0/2] new kfifo API
    ... and I disagree about the locking changes. ... but the first patch will break something. ... interface work in an entirely safe way (kfifo_get doing all the ... The design is to have variable length records, so it it not always true ...
    (Linux-Kernel)
Quantcast