[ovs-dev] [PATCH v2] lib/dpif-netdev: Integrate megaflow classifier.

Alex Wang alexw at nicira.com
Tue Oct 14 01:51:04 UTC 2014


Hey Jarno,

I have some high-level comments/questions as follow:

On Tue, Oct 7, 2014 at 2:43 PM, Jarno Rajahalme <jrajahalme at 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.



More information about the dev mailing list