On Wed, Feb 03, 2010 at 01:38:09PM -0500, Jon Masters wrote: > *). Per namespace cacheing allocation (the cachep bits). We know it's > still possible for weirdness to happen in the SLAB cache here. Tiny race, needs reproducer. > *). Per namespace hashsize tracking. Existing code corrupts hashtables > if the global size is changed when there is more than one netns I think, no. Changing hash size will change hashsize for all netns, current and future. > *). Per namespace expectations. This is for similar reasons to the need > for multiple hashtables, though I haven't poked at that. Expectation cache is not SLAB_DESTROY_BY_RCU, so the logic doesn't apply, I hope. > I also think it is necessary to expose net namespace layout Not necessary. Why? > and configuration via sysfs Which configuration? > or some other interface, add a net->id parameter (and may even an optional name), No name, please :-) ->id is more or less required for per-netns conntrack cache. > etc. Where does netns discussion happen, on netdev I would presume? Yep. And containters@, I think. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
