On Mon, Oct 13, 2014 at 6:51 PM, Alex Wang <al...@nicira.com> wrote:

> 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.
>
>


Based on discussion offline, we will still need to keep the classifier and
the
'cmap' flow table updates in sync.  We could recheck for any further
optimizations after per pmd thread classifier/flow table change is done.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to