There are many reasons for reloading of pmd threads: * reconfiguration of one of the ports. * Adjusting of static_tx_qid. * Adding new tx/rx ports.
In many cases EMC is still useful after reload and uninit will only lead to unnecessary upcalls/classifier lookups. Such behaviour slows down the datapath. Uninit itself slows down the reload path. All this factors leads to additional unexpected latencies/drops on events not directly connected to current PMD thread. Lets not uninitialize emc cache on reload path. 'emc_cache_slow_sweep()' and replacements should free all the old/unwanted entries. Signed-off-by: Ilya Maximets <i.maxim...@samsung.com> Acked-by: Cian Ferriter <cian.ferri...@intel.com> Tested-by: Cian Ferriter <cian.ferri...@intel.com> --- lib/dpif-netdev.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c index a1e8c56..74d3535 100644 --- a/lib/dpif-netdev.c +++ b/lib/dpif-netdev.c @@ -3810,9 +3810,9 @@ pmd_thread_main(void *f_) ovs_numa_thread_setaffinity_core(pmd->core_id); dpdk_set_lcore_id(pmd->core_id); poll_cnt = pmd_load_queues_and_ports(pmd, &poll_list); + emc_cache_init(&pmd->flow_cache); reload: pmd_alloc_static_tx_qid(pmd); - emc_cache_init(&pmd->flow_cache); /* List port/core affinity */ for (i = 0; i < poll_cnt; i++) { @@ -3866,13 +3866,13 @@ reload: * reloading the updated configuration. */ dp_netdev_pmd_reload_done(pmd); - emc_cache_uninit(&pmd->flow_cache); pmd_free_static_tx_qid(pmd); if (!exiting) { goto reload; } + emc_cache_uninit(&pmd->flow_cache); free(poll_list); pmd_free_cached_ports(pmd); return NULL; -- 2.7.4 _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev