Hey Jarno, I have some high-level comments/questions as follow:
On Tue, Oct 7, 2014 at 2:43 PM, Jarno Rajahalme <jrajaha...@nicira.com> wrote: > flow inserts and removals are simplified: > > - No need for classifier internal mutex, as dpif-netdev already has a > 'flow_mutex'. > I'm thinking maybe we should keep the per-classifier mutex and get rid of the 'flow_mutex' (make the code simpler). The reason we use flow_mutex on current master is that we need to include the lookup 'dp_netdev_lookup_flow()' into the critical section (e.g. in 'fast_path_processing()', since two or more pmd threads could be trying to install the same dp flow). If we change to per-pmd thread classifier/flow-table, then the situation like above will not happen. Instead, we are facing the issue of pmd thread trying to install and revalidator thread trying to delete at the same time. In that case, I think we just need classifier internal mutex to protect the access to cmap. However, there could be one exception, which is using ovs-appctl dpctl/* cmds to add/del flows (main thread and pmd thread could install the same flow at same time). We could workaround it by registering the flow operation and have pmd thread execute it. What do you think? There could be other cases I missed, that makes the flow_mutex required. ;D > - Number of memory allocations/frees can be halved. > Are you referring to getting rid of 'cls_match_alloc()' called in insert_rule() ? > Lookup code path is a bit more effcient as well, as we can rely on > netdev_flow_key always having inline data. > will take a closer look of the code later. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
