On Thu, 3 Sep 2020 12:53:02 +0800 Suanming Mou <suanmi...@nvidia.com> wrote:
> Currently, the rte flow functions are not defined as thread safety. > DPDK applications either call the functions in single thread or add > locks around the functions for the critical section. > > For PMDs support the flow operations thread safe natively, the > redundant protection in application hurts the performance of the > rte flow operation functions. > > And the restriction of thread safety not guaranteed for the rte > flow functions also limits the applications' expectation. > > This feature is going to change the rte flow functions to be thread > safety. As different PMDs have different flow operations, some may > support thread safety already and others may not. For PMDs don't > support flow thread safe operation, a new lock is defined in ethdev > in order to protects thread unsafe PMDs from rte flow level. > > A new RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE device flag is added to > determine whether the PMD supports thread safe flow operation or not. > For PMDs support thread safe flow operations, set the > RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE flag, rte flow level functions will > skip the thread safe helper lock for these PMDs. Again the rte flow > level thread safe lock only works when PMD operation functions are > not thread safety. > > The change has no effect on the current DPDK applications. No change > is required for the current DPDK applications. > > Signed-off-by: Suanming Mou <suanmi...@nvidia.com> What is the performance impact of this for currently working applications that use a single thread to program flow rules. You are adding a couple of system calls to what was formerly a totally usermode operation.