Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 30 Jan 2012 17:11:45 +0100
From:      =?ISO-8859-1?Q?Ermal_Lu=E7i?= <eri@freebsd.org>
To:        freebsd-ipfw@freebsd.org
Subject:   Fwd: [PATCH] multiple instances of ipfw(4)
Message-ID:  <CAPBZQG3H3=mAC6C9EiQwSMSszZbXwqU=OvX9NZkMERDfGAXByQ@mail.gmail.com>
In-Reply-To: <CAPBZQG32iyzkec4PG%2Bqay9bKfd0GiffKyRBapLkATKvHr7cVww@mail.gmail.com>
References:  <CAPBZQG32iyzkec4PG%2Bqay9bKfd0GiffKyRBapLkATKvHr7cVww@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Maybe this list is more appropriate!


---------- Forwarded message ----------
From: Ermal Lu=E7i <eri@freebsd.org>
Date: Mon, Jan 30, 2012 at 1:01 PM
Subject: [PATCH] multiple instances of ipfw(4)
To: freebsd-net <freebsd-net@freebsd.org>, freebsd-hackers@freebsd.org


Hello,

from needs on pfSense a patch for allowing multiple intances of
ipfw(4) in kernel to co-exist was developed.
It can be found here
https://raw.github.com/bsdperimeter/pfsense-tools/master/patches/RELENG_9_0=
/CP_multi_instance_ipfw.diff

It is used in conjuction with this tool
https://raw.github.com/bsdperimeter/pfsense-tools/master/pfPorts/ipfw_conte=
xt/files/ipfw_context.c
It allows creation of contextes/instances and assignment of specific
interfaces to specific contexts/instances.

Surely i know that this is not the best way to implement generically
but it gets the job done for us as it is, read below.

What i would like to know is if there is interest to see such
functionality in FreeBSD?

I am asking first to see if there is some consensus about this as a
feature, needed or not!
If interest is shown i will transform the patch to allow:
- ipfw(8) to manage the contextes create/destroy
- ipfw(8) to manage interface membership. Closing the race of two
parallell clients modifying different contextes.

There is another design choice to be made about storing the membership
of interfaces into contexts/instances, but i do not see that as
blocking.

It is quite handy feature, which can be exploited even to scale on SMP
machines by extending it to bind a specific instance(with its
interaces) to a specific CPU/core?!

Comments/Feedback expected,
Ermal



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPBZQG3H3=mAC6C9EiQwSMSszZbXwqU=OvX9NZkMERDfGAXByQ>