From: Venkat Yekkirala <[EMAIL PROTECTED]>
Date: Wed, 1 Feb 2006 10:43:09 -0500
> I see this uses netlink which uses wait queues. Could using wait queues be a
> solution to the PF_KEY problem?
PF_KEY is always going to do badly here because it wants to stuff the
entire response into the socket i
On Wed, 2006-01-02 at 10:43 -0500, Venkat Yekkirala wrote:
> I have tried "ip xfrm policy list" and it dumps all the thousands of rules,
> no problem.
>
> I see this uses netlink which uses wait queues. Could using wait queues be a
> solution to the PF_KEY problem?
>
Give it a shot with wait que
> Sent: Tuesday, January 31, 2006 10:59 AM
> To: Venkat Yekkirala
> Cc: netdev@vger.kernel.org; Chad Hanson; Darrel Goeddel
> Subject: Re: IPSec DUMP issue
>
>
> On Tue, 2006-31-01 at 11:42 -0500, Venkat Yekkirala wrote:
>
>
> > I gather this is a known iss
jamal wrote:
> On Tue, 2006-31-01 at 11:42 -0500, Venkat Yekkirala wrote:
>
>
>
>>I gather this is a known issue and was wondering about possible/acceptable
>>solutions as I would like to help resolve this problem.
>>
>
>
> Pseudo-known issue. The challenge is pfkey which doesnt scale well.
>
On Tue, 2006-31-01 at 11:42 -0500, Venkat Yekkirala wrote:
> I gather this is a known issue and was wondering about possible/acceptable
> solutions as I would like to help resolve this problem.
>
Pseudo-known issue. The challenge is pfkey which doesnt scale well.
Try dumping with iproute2 ip xf
Hello,
When there is a lot (thousands) of IPSec policy rules in the kernel, a dump
request from user land would currently cause most of the policy rules to not
make it to the socket receive buffer depending on what value sk_rcvbuf has.
Using setkey to load a bunch of policy rules, then trying to d
