On Mon, 2005-19-12 at 23:38 -0800, David S. Miller wrote: > This patch below illustrates the general idea. It compiles, > and that is all I guarentee :-) > > We add backpointers to the xfrm_dsts's that compose a bundle, > back to the root of the bundle. > > Every time we build a bundle, we add each xfrm_dst into a list > hung off of the xfrm_state. >
"build a bundle" as in when the policy tmpl is resolved? [i.e xfrm_lookup()::bundle_create()]. Looking at the patch, i couldnt see where you are doing this and that would probably be one good spot. > Then at xfrm_state delete time we kill all bundles referring to that > xfrm_state. (what's extremely odd is that if you go deep into the > IPSEC stack code history, we used to do it like this, but stopped > doing so for some reason... probably some locking issue) > > When inserting a new rule we flush all bundles referring to > xfrm_state's which have the same "ID" as the newly inserted bundle. > We can find such things precisely. > And since the bundles are built at runtime, it is just a little tiny one time setup cost over what we do today (unlike the "lets check state every packet to see if we need to obsolete"). Overall the idea is clever. What are you on Dave?;-> give me some of that ;-> > We don't need to do the flushing from the workqueue any more > because we don't try to take locks recursively. (the old > problem was xfrm_set_mtu() called from stale_bundle() which > would try to re-take the xfrm_state->lock). > > The remaining gap is the policy bundle list. That's the remaining > inefficient data structure that limits performance in this area, but > this patch makes it no worse and no better. Why is the policy bundle list inefficient? cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
