> On Mon, Nov 28, 2005 at 01:42:41PM +0300, [EMAIL PROTECTED] wrote:
> .> > On Mon, Nov 28, 2005 at 08:27:32AM +0200, Ruslan Ermilov wrote:
> .> > R> > Can you try my patch? Since it reduces the total number of mutex
> .> > R> > operations it should be a win on UP, too.
> .> > R> We're currently ba
Gleb Smirnoff wrote:
> On Mon, Nov 28, 2005 at 06:04:50PM +0100, Max Laier wrote:
> M> I remember that we had an extensive discussion about this around
> M> FreeBSD-SA-05:13.ipfw - the bottom line seems to be: either parallel or
> M> cacheing. Stack storage should work as well.
>
> The cacheing i
On Sun, Nov 27, 2005 at 10:00:01PM +0200, Mihail Balikov wrote:
M> I have made small patch to cache results per "table" and this caching gives
M> me about 92% hit ratio with a lot of session.
Can you show us the patch. How many parallel sessions are there?
--
Totus tuus, Glebius.
GLEBIUS-RIPN G
On Mon, Nov 28, 2005 at 08:32:36AM -0800, Luigi Rizzo wrote:
L> Given that you (Gleb) are putting in some new features, I would
L> suggest a variant to your tablearg thing, i.e.
L>
L> + a 'setvar index value' which can be put as an always-true
L>option within a rule e.g. to store partial eval
On Mon, Nov 28, 2005 at 06:04:50PM +0100, Max Laier wrote:
M> On Monday 28 November 2005 17:19, Gleb Smirnoff wrote:
M> > The number 65535 is some magic number, which means "take argument from
M> > table". I will make ipfw display some word instead of 65535, for example
M> > "tablearg". So, the rul
On Monday 28 November 2005 17:19, Gleb Smirnoff wrote:
> The number 65535 is some magic number, which means "take argument from
> table". I will make ipfw display some word instead of 65535, for example
> "tablearg". So, the rule will be looking like:
>
> pipe tablearg ip from any to table(1)
the pipe-pointer within an ipfw rule is just for optimizing
the lookup.
Surely there is a better way to do this e.g. looking up pipes
through a hash table. In fact, the same might be done for rule
lookups.
Given that hash tables are already implemented in both ipfw and dummynet
for the dynamic rul
Ruslan,
okay, I have implemented a feature that allows to merge your ruleset
into one rule. Look how it works:
[EMAIL PROTECTED]:~:|>kldload dummynet
[EMAIL PROTECTED]:~:|>ipfw pipe 2 config
[EMAIL PROTECTED]:~:|>ipfw pipe 3 config
[EMAIL PROTECTED]:~:|>ipfw add 1000 pipe 65535 ip from any to
On Mon, Nov 28, 2005 at 01:42:41PM +0300, [EMAIL PROTECTED] wrote:
.> > On Mon, Nov 28, 2005 at 08:27:32AM +0200, Ruslan Ermilov wrote:
.> > R> > Can you try my patch? Since it reduces the total number of mutex
.> > R> > operations it should be a win on UP, too.
.> > R> We're currently based on 4.x
> On Mon, Nov 28, 2005 at 08:27:32AM +0200, Ruslan Ermilov wrote:
> R> > Can you try my patch? Since it reduces the total number of mutex
> R> > operations it should be a win on UP, too.
> R> We're currently based on 4.x. You can try it yourself: create
> R> a table with 1 entries and with val
On Mon, Nov 28, 2005 at 08:27:32AM +0200, Ruslan Ermilov wrote:
R> > On Sun, Nov 27, 2005 at 09:45:45PM +0200, Ruslan Ermilov wrote:
R> > R> Nope, I need this caching. It's for looking up the same table
R> > R> several times in a row but with various values. For example,
R> > R> we use ipfw table
On Sun, Nov 27, 2005 at 10:59:14PM +0300, Gleb Smirnoff wrote:
> Ruslan,
>
> On Sun, Nov 27, 2005 at 09:45:45PM +0200, Ruslan Ermilov wrote:
> R> Nope, I need this caching. It's for looking up the same table
> R> several times in a row but with various values. For example,
> R> we use ipfw tab
Gleb Smirnoff wrote:
On Sun, Nov 27, 2005 at 03:59:43AM +0300, Gleb Smirnoff wrote:
T> A patch displaying the idea is attached. Not tested yet, read
T> below. The patch moves the tables array into the ip_fw_chain
T> structure. This is not necessary now, but in future we can
T> have multiple inde
d Lobko" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Sunday, November 27, 2005 9:45 PM
Subject: Re: parallelizing ipfw table
> On Sun, Nov 27, 2005 at 04:55:29PM +0300, Gleb Smirnoff wrote:
> > On Sun, Nov 27, 2005 at 03:59:43AM +0300, Gleb
Ruslan,
On Sun, Nov 27, 2005 at 09:45:45PM +0200, Ruslan Ermilov wrote:
R> Nope, I need this caching. It's for looking up the same table
R> several times in a row but with various values. For example,
R> we use ipfw tables to route the traffic to the correct dummynet
R> pipe, where value is th
On Sun, Nov 27, 2005 at 04:55:29PM +0300, Gleb Smirnoff wrote:
> On Sun, Nov 27, 2005 at 03:59:43AM +0300, Gleb Smirnoff wrote:
> T> A patch displaying the idea is attached. Not tested yet, read
> T> below. The patch moves the tables array into the ip_fw_chain
> T> structure. This is not necessary
On Sun, Nov 27, 2005 at 03:59:43AM +0300, Gleb Smirnoff wrote:
T> A patch displaying the idea is attached. Not tested yet, read
T> below. The patch moves the tables array into the ip_fw_chain
T> structure. This is not necessary now, but in future we can
T> have multiple independent chains in ipfw,
On Sun, Nov 27, 2005 at 03:59:43AM +0300, Gleb Smirnoff wrote:
T> Colleagues,
T>
T> in ipfw(4) we've got a reader/writer locking semantics. The ipfw
T> lookups performed on packet forwarding obtain reader lock on ipfw
T> chain, while altering the chain requires writer access on chain.
T>
T> S
18 matches
Mail list logo
