On Fri, Sep 23, 2011 at 02:20:17PM -0700, Jesse Gross wrote: > Currently it is possible for a client on a single port to generate > a huge number of packets that miss in the kernel flow table and > monopolize the userspace/kernel communication path. This > effectively DoS's the machine because no new flow setups can take > place. This adds some additional fairness by separating each upcall > type for each object in the datapath onto a separate socket, each > with its own queue. Userspace then reads round-robin from each > socket so other flow setups can still succeed. > > Since the number of objects can potentially be large, we don't always > have a unique socket for each. Instead, we create 16 sockets and > spread the load around them in a round robin fashion. It's theoretically > possible to do better than this with some kind of active load balancing > scheme but this seems like a good place to start. > > Feature #6485
Seems reasonable. Again I'd rate-limit the new warnings in set_upcall_pids(). The call to dpif_flow_dump_next() should supply NULL for the actions and n_actions parameters since it doesn't need the actions. This is a significant optimization because of how dfpi_linux_flow_dump_next() is implemented. (I think I should have mentioned the same thing in an earlier patch but I didn't notice until now.) Thanks, Ben. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
