From: Joy L. <la...@au...> - 2007-07-16 20:42:47
|
On Mon, 2007-07-16 at 13:10 +0000, Matthew Grooms wrote: > On 7/16/2007, "Scott Lamb" <sl...@sl...> wrote: > >VANHULLEBUS Yvan wrote: > >> > >> The first performance problem is the PFKey interface itself, because > >> one message request (SADB_X_SPDDUMP, or something like that) will > >> generate one kernel response per SPD entry (yes....). > > > >Why is that a problem? This is asymptotically insignificant. > > > > As racoon runs a single process, there could potentially be a problem if > it happens to be doing something else between reads from the pfkey > socket. One example could be performing a select on another file > descriptor. If you are seeing high cpu utilization during the initial > spd dump processing, this is most likely not the case. > > >> The second performance problem is the SPD matching code, where each > >> new SPD received from the kernel will be compared against all other > >> SPD entries. > >> > >> This will be a good thing to clean up / speed up that, but I'll have > >> to verify the exact constraints of the SPD list before. > >> > > I believe you agree with Yvan here in your last statement. > > >> And this won't solve the PFKey problem... > >> For that, I guess Linux kernels don't have the problem because they > >> don't really use PFKey interface (well, that's what I understood a > >> long time ago...) > > > >Linux kernels use the same interface as BSD ones. This problem was > >encountered on Linux, not BSD. > > > > I think Yvan was just stating that the PFKEY protocol implementations on > Linux and BSD have operational differences. Obviously, they use the same > interface as defined in the PFKEY RFC etc. > Yes. I also wondered if he might be referring to the netlink xfrm api in Linux. It provides same abilities as pfkey but overcomes some known limitations with pfkey, specifically in regards to buffer sizes when dumping info, like spd entries. See http://sourceforge.net/mailarchive/forum.php?thread_name=20060208180357.55191.qmail%40web30915.mail.mud.yahoo.com&forum_name=ipsec-tools-devel > >>, and the only solution I have for BSD kernels is a > >> big hack, with a new SADB_X_SPDDUMP_ONEBLOCK (call it as you like) > >> PFKey message, where the userland gives the base address and size of a > >> big memory block, and where the kernel fills all the informations in > >> the memory block. > >> > >> It works, but we still have a problem: setiing up a correct size for > >> the memory block..... > > > >The time is going into racoon2's O(n^2) algorithm, so I'm not sure why > >you think an interface change would solve it. And I have no idea why you > >would violate the clean message-based protocol like that. > > > > Yvan can correct me if my memory if faulty here, but I believe he was > referring to work around for a BSD kernel limitation where you can reach > an entry limit relatively quickly. I doubt this would apply to Linux > kernels. > > It sounds like everyone is basically saying the same thing. We just need > to come up with patch that provides an acceptable solution. > Regards, Joy |