> From: Jan Scheurich > Sent: Thursday, 07 July, 2016 10:28 > > I actually have some doubts about thread safety of the dpcls complex. My > understanding is that dpcls rules are inserted only by the owning PMD thread > itself as result of processing upcalls. But dplcs rules are removed by > revalidator threads as part of deletion of e.g. expired dpif flow entries. I > may > be missing something here, but I don't see how struct dpcls and its > constituent parts (struct cmap subtables_map, struct pvector subtables, > struct dpcls_subtable's cmap rules) are protected against concurrent > modifications by the owning PMD and revalidator threads.
I realized that pmd->flow_mutex is used to prevent simultaneous updates of the flow table and dplcs classifiers by PMD thread and revalidator thread. So my thread safety concern seems taken care of. But it also means that the PMD thread may block for flow installation after an upcall. The flow_mutex is only taken by the revalidator process for deleting one flow at a time, so the exclusion period is not very long, but it there is a risk that interference between upcalls and revalidator sweeps slow down the PMD. Have you measured the effect of the additional mutex after upcall and taken a conscious decision to keep it that way? In any case, I believe my patch cannot be applied without synchronizing through flow_mutex while optimizing the subtable vectors. Would that be acceptable every second? One alternative could be to run timer-controlled optimization from a non-PMD thread and synchronize that through the flow_mutex. This would only block the PMD if an upcall hit an ongoing optimization. The optimal solution would probably be to do all modifications within the PMD thread and pass the flow delete requests from revalidator to PMD thread through a (pair of) DPDK ring(s). Regards, Jan _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
