RELENG_5 and FAST_IPSEC limits

[Hajimu UMEMOTO]

Hi,

>>>>> On Thu, 17 Mar 2005 09:00:06 -0800
>>>>> Sam Leffler <sam at errno.com> said:

sam> Possibly; I can't tell from the patch if locks are held across calls 
sam> they should not be. I also worry about the effect of holding the various 
sam> locks for an extended period of time (will it impact packet processing?)

Since key_setdump() which is substantial function of KEYCTL_DUMPSA
sysctl does in much the same way as key_dump(), I added locking in a
similar manner.  So, I believe period of time for holding the locks is
differ little from key_dump().  However, sysctl required calling
key_setdump() twice; 1st is for getting data size and 2nd is for
actuall query.

sam> Are you suggesting KAME code can/will change to eliminate the use of 
sam> PF_KEY sockets to query the SA db state?

It seems that SADB_DUMP is useless on large system, and we need an
alternative for it.  Once we introduce an alternative, we don't need
SADB_DUMP within our tree.
However, SADB_DUMP is defined in RFC 2367 and deployed.  So, we should
not eliminate it for now.  I hope it should be deprecated in the
future.

The reason I'm going to bring KEYCTL_DUMPSA sysctl into FreeBSD is
that there is implementation and Racoon supports it as well.  NetBSD
has KEYCTL_DUMPSA already, and OpenBSD added similar sysctl recently.

I wonder if KEYCTL_DUMPSA sysctl is good for alternative.  We need to
call sysctl twice for variable length data such as SA dump.  It may
become overhead.  Further, data size is unassured to be same between
these two sysctl call.  If data grows, 2nd sysctl call will fail.
In anyway, it solves a limitation of SADB_DUMP.

Sincerely,

--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
ume at mahoroba.org  ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/