On 01/21/15 at 04:08pm, Herbert Xu wrote: > On Tue, Jan 20, 2015 at 03:35:56PM +0000, Thomas Graf wrote: > > On 01/20/15 at 03:21pm, Patrick McHardy wrote: > > > I think its preferrable to make the need to handle NETLINK_F_DUMP_INTR > > > as noticable as possible and not hide it. Silent failure is the worst > > > kind of failure. > > > > I agree to that. The point here is to avoid unnecessary use of > > NETLINK_F_DUMP_INTR if all entries fit into a single message buffer. > > OK I think I have a solution for you guys. But first you'll need to > wait for me to undo the nulls stuff so I can steal that bit which > is central to my solution. Without having seen your code, can we make it configurable on what the bit is used for? Use of nulls marker is a strict requirement for some targeted users of rhashtable. > Essentially I need a bit to indicate an entry in the bucket chain > should be skipped, either because it has just been removed or that > it is a walker entry (see xfrm_state_walk). > > The way it'll work then is exactly the same as xfrm_state_walk, > except that the linked list is broken up into individual buckets. > > Of course we'll still need to postpone resizes (and rehashes which > is what my work is about) during a walk but I think that's a fair > price to pay. If I understand this correctly we also need to block out parallel walkers and we need to start taking bucket locks while walking to modify the walker mark bit in peace. > This also means handling insertion failures but I think that > should be acceptable if we make it based on a configurable maximum > chain length along with forced resize/rehash where possible. > > Note that this can be made optional, i.e., if the user can afford > memory to do their own walking (e.g., xfrm_state), then none of > this needs to happen and it'll just work as it does now. IOW if > you don't use this special rhashtable walk function then you're > not affected. That sounds like the best option to me. -- 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
