Date: Fri, 22 Jan 2016 16:29:40 +0000 From: Taylor R Campbell <[email protected]>
Part (2) makes ip_encap scale well to many cores, but it stops ip_encap from scaling well to many tunnels, because it removes the radix tree. Maybe that's OK -- maybe today, scaling to many cores is more important than scaling to many tunnels. Oops -- I didn't read encap4/6_lookup closely enough. They *always* iterate over the entire list of tunnels and call every relevant function stored there to prioritize matches. So the radix tree probably never did help (much) to scale to many tunnels after all, and my concern was entirely moot! If you want to skip the radix tree, I suggest committing essentially the reverse of ip_encap.c 1.45 first (remove old USE_RADIX case), separately from any MP issues. That said, it is still not clear to me how you guarantee the tunnel will continue to exist in encap4/6_input, after pserialize_read_exit and during the call to psw->pr_input. I also wonder whether it is OK to call ep->func inside a pserialize read section: it enters a lot of nested callbacks in the network stack which don't look safe to me. For example, gif_encapcheck4 calls gif_validate4 calls rtalloc1 which doesn't look very safe for pserialize read to me.
