From: jamal <[EMAIL PROTECTED]>
Date: Mon, 04 Dec 2006 15:58:03 -0500
> This one has undergone more scrutiny and testing. Against net-2.6.20
Applied, thanks Jamal.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Dave,
This one has undergone more scrutiny and testing. Against net-2.6.20
cheers,
jamal
[XFRM] Optimize policy dumping
This change optimizes the dumping of Security policies.
1) Before this change ..
speedopolis:~# time ./ip xf pol
real0m22.274s
user0m0.000s
sys 0m22.269s
2) Turn
On Mon, 2006-04-12 at 18:59 +0100, Patrick McHardy wrote:
> jamal wrote:
> I'd prefer if you did it since you're already testing the thing :)
Ok, will do shortly.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More
jamal wrote:
> Ok, both looked good except for the test of a single entry.
> This was because you would break out of the loop with count of 0.
> The patch against yours would look like something attached for the state
> case. Dont forget there are two spots on the policy side of things;->
You're r
On Mon, 2006-04-12 at 16:55 +0100, Patrick McHardy wrote:
> This patch should fix it (and is even simpler), by moving the
> check for pol->type != type before sending, we make sure that
> last always contains a valid element unless count == 0.
>
> Also fixed an incorrect gcc warning about last_d
Patrick McHardy wrote:
> jamal wrote:
>
>>All the way down, you call func with a NULL entry. You could add a check
>>to make sure it only gets invoked when last is not null, but the result
>>is in such a case, you will never send a 0 count element. I am sure
>>there could be other tricky scenarios
jamal wrote:
> On Mon, 2006-04-12 at 09:05 -0500, jamal wrote:
>
>>Patrick,
>>
>>Your approach is much cleaner. Let me give these a few tests then
>>I will repost later today; forget about the callback approach for now.
>>
>
>
> I have just applied the policy patch; havent compiled or tested (th
On Mon, 2006-04-12 at 09:05 -0500, jamal wrote:
> Patrick,
>
> Your approach is much cleaner. Let me give these a few tests then
> I will repost later today; forget about the callback approach for now.
>
I have just applied the policy patch; havent compiled or tested (the
setup takes me a while
jamal wrote:
> On Mon, 2006-04-12 at 15:06 +0100, Patrick McHardy wrote:
>
>
>>Both ways are fine I guess. But the counting has almost no
>>overhead with the patch I sent, so I'm not sure if its worth
>>adding a callback (which still needs to get the last policy/SA
>>as argument, so that part won
On Mon, 2006-04-12 at 15:06 +0100, Patrick McHardy wrote:
> Both ways are fine I guess. But the counting has almost no
> overhead with the patch I sent, so I'm not sure if its worth
> adding a callback (which still needs to get the last policy/SA
> as argument, so that part won't get any nicer).
>
Patrick,
Your approach is much cleaner. Let me give these a few tests then
I will repost later today; forget about the callback approach for now.
cheers,
jamal
On Mon, 2006-04-12 at 08:58 -0500, jamal wrote:
> On Mon, 2006-04-12 at 14:57 +0100, Patrick McHardy wrote:
>
> > I think the complica
jamal wrote:
> On Mon, 2006-04-12 at 14:57 +0100, Patrick McHardy wrote:
>
>
>> I think the complications come from the fact that you remeber two
>> policies, but only one seems necessary. How about this (completely
>> untested) patch? It simply uses increasing sequence numbers for all
>> but th
On Mon, 2006-04-12 at 14:57 +0100, Patrick McHardy wrote:
> I think the complications come from the fact that you remeber two
> policies, but only one seems necessary. How about this (completely
> untested) patch? It simply uses increasing sequence numbers for all
> but the last entry and use
Patrick McHardy wrote:
> jamal wrote:
>
>>All very valid points.
>>Yikes, the directionality is not something i thought clearly about or
>>tested well. I can fix this but this code will only get fuglier. How
>>about the following approach:
>>
>>I add a new callback which is passed in the invocatio
jamal wrote:
> All very valid points.
> Yikes, the directionality is not something i thought clearly about or
> tested well. I can fix this but this code will only get fuglier. How
> about the following approach:
>
> I add a new callback which is passed in the invocation to walk.
> This callback
On Mon, 2006-04-12 at 13:24 +0100, Patrick McHardy wrote:
> A few cases that will behave incorrectly:
>
> - two policies in xfrm_policy_inexact with the same direction:
> after the first iteration we have last_pol = send_pol = first policy
> and no messages sent, after the second iteration we
jamal wrote:
> diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
> index 64d3938..c8a98ca 100644
> --- a/net/xfrm/xfrm_policy.c
> +++ b/net/xfrm/xfrm_policy.c
> @@ -860,57 +860,70 @@ EXPORT_SYMBOL(xfrm_policy_flush);
> int xfrm_policy_walk(u8 type, int (*func)(struct xfrm_policy *, int,
This improves dumping performance of xfrm policies. I started getting
bothered when i noticed it took upto a minute dumping 60K policies from
the kernel.
I have another one i am testing that uses the same approach for SAs.
Will send in the next hour.
Against net-2.6.20.
cheers,
jamal
[XFRM] Opti
18 matches
Mail list logo
