Create hash table based on primary or secondary proc

[dennisafa]

As pointed out by @koolzz, we should only call rte_hash_create() from the primary process. NF's would call onvm_ft_create() and call rte_hash_create() as a secondary process, which DPDK does not allow

Summary:

When onvm_ft_create is called, whether from an NF or the manager, we now check what process type it is being called from with rte_eal_process_type() If it's a secondary process (called from an NF) then we'll make the manager initialize our hash_table using a mechanism that is similar to @AaronCoplan 's firewall LPM request method.

Usage: Run the manager, then run any NF that calls onvm_ft_create. flow_tracker is one example.

This PR includes
Resolves issues
Breaking API changes
Internal API changes	X
Usability improvements
Bug fixes	X
New functionality
New NF/onvm_mgr args
Changes to starting NFs
Dependency updates
Web stats updates

Merging notes:

• Dependencies: None

TODO before merging :

• [x] PR is ready for review

Test Plan:

Run the manager, then run the flow_tracker or the load_balancer NF and test its functionality.

Review:

@koolzz @kevindweb

[onvm]

In response to PR creation

CI Message

Your results will arrive shortly

[twood02]

Does the current code call the hash create functions in a secondary process? Does this mean that our current flow table code just doesn't work?

[koolzz]

@twood02 yes currently it's called from secondary process, it works but dpdk says that it's not okay. And I think currently it can have issues with a secondary process running on a different cpu socket or something along those libes

[dennisafa]

yes. also when created from a secondary process hash_create sporadically fails and throw a rte_hash_create failed: could not create hash table

[dennisafa]

Lgtm, do we have a NF that uses the flow table so we can test this?

yes, flow_tracker uses it. a pktgen sanity check would be ideal

[kevindweb]

So just so I'm on the same page, instead of calling rte_hash_create from the subprocess here you are enqueueing a message so that our main thread picks it up and creates it (because dpdk doesn't like subprocesses creating)?

[kevindweb]

Before you get back to me, I did performance test everything, Pktgen looks solid, did a few shared core speed_tester extreme tests as well and it looked clean.

[dennisafa]

So just so I'm on the same page, instead of calling rte_hash_create from the subprocess here you are enqueueing a message so that our main thread picks it up and creates it (because dpdk doesn't like subprocesses creating)?

yea. if rte_hash_create is called from a secondary process, manager (primary process) will create it via this message system. RTE_PROC_TYPE tells us what kind of process it is.

[koolzz]

@onvm CI before improve

[onvm]

@onvm CI before improve

CI Message

Your results will arrive shortly