[ovs-dev] [PATCH] upcall: Configure datapath max-unkeep-op through ovs-vsctl.

wenxu wenxu at ucloud.cn
Tue Oct 8 07:01:44 UTC 2019

On 10/1/2019 4:29 AM, Ben Pfaff wrote:
> On Mon, Sep 30, 2019 at 07:15:39PM +0800, wenxu at ucloud.cn wrote:
>> From: wenxu <wenxu at ucloud.cn>
>> This patch adds a new configuration option, "max-unkeep_op" to the
>> Open_vSwitch "other-config" column. This sets maximum allowed ravalidator
>> do the UNKEEP operations with limit in each dump.
>> In the hw-offload mode. The huge number of UNKEEP operationes will
>> make  revalidator block long time.
> Thanks for working to make OVS perform better.
> It's best if OVS can perform well without requiring users to tune it by
> hand.  This commit does not try to do that; instead, users have to
> notice that there is a performance problem, find this particular
> setting, and then experiment to find the best value.  That's a lot of
> work.  Can you try to make this self-tuning, so that users don't have to
> go through all of that?
> Second, when OVS does require manual tuning for best performance, we
> should try to document the settings' purpose and rationale and how to
> determine their values.  The name for this setting is not informative (I
> do not understand it myself) and the documentation does not explain what
> it is for, how one should recognize that tuning it is necessary, or how
> to choose a useful value.
> Will you please take another look to see if you can improve the patch
> along those two axes?  Thanks again for working to make OVS faster.

Hi ben,

Thx.  I  found the root cause of the bad performance  delete tc flower rule in revalidator threads.

All the block is for the  netdev_hmap_mutex mutex. In the netdev_ports_get the handler with compete with

revlalidator. The netdev_ifindex_to_odp_port and netdev_ports_flow_del with this mutex will bolock revalidator each other. So Maybe replace the hmap to rcuhlist is much better?  But there is no such rcuhlist utilitis in the lib

More information about the dev mailing list