Closed dennisafa closed 4 years ago
In response to PR creation
Your results will arrive shortly
@onvm will you play nice?
@onvm maybe with the config?
@onvm maybe with the config?
Your results will arrive shortly
@onvm again
@onvm again
Your results will arrive shortly
@onvm ubuntu 18! nimbnode1 let's go!
@onvm ubuntu 18! nimbnode1 let's go!
Your results will arrive shortly
@onvm ubuntu 18! nimbnode1 let's go!
Error: ERROR: Failed to copy ONVM files to nimbnode17
pasta
Your results will arrive shortly
pasta 2
Your results will arrive shortly
pasta 2
Error: ERROR: Failed to fetch results from nimbnode17
@onvm please grab the files this time
@onvm please grab the files this time
Your results will arrive shortly
@onvm please grab the files this time
Error: ERROR: Script failed on nimbnode17
@onvm can you be kind
@onvm can you be kind
Your results will arrive shortly
@dennisafa good find, this seems easily detectable if we set some flags during init process. Can you create a task for that/submit a pr if you have time.
thanks @kevindweb and @koolzz! yes, I will look into modifying init to check for this.
May i depict a problem , in ./go.sh 0,1,2,3 3 0xF0 -s stdout the load-generator run well, but i test in share core ./go.sh 0,1,2,3 3 0xF0 -s stdout -c ,the load-generator not run . In OpenNetVM V 19.07.
@Yongeverhuang Thanks for your comment. The only way I could replicate this issue was by having no active igb_uio devices loaded. If an active port is not detected, then mempools are not properly set up leading to that issue. Please verify that the manager + load_generator look like this when active:
As a side note, a warning message in the NF should pop up indicating that no port is present.
@dennisafa Thanks for help . Let me make a full description . In no share core way, run ./go.sh 0,1,2,3 0x1 0xF0 -s stdout in the manager ,the load_generator work well, like this But then ,run in share mode , it doesn't work ,amd no warning message pop up .Like this , the load_generator not run unless ctrl -c stop it ,the screen print out that. It seems looks like usual when run other NF when in share core mode. Such speed-tester .
Thank you for the screenshots. What branch of openNetVM are you running? Also, what command are you running to initiate the manager in shared core mode?
It also seems like you are using the -t
argument. This will shut down the NF after a period of time.
@dennisafa Thanks! In my test ,i use the latest OpenNetVM. In no share mode : manager: ./go.sh 0,1,2,3 0x1 0xF0 -s stdout load_generator : ./start_nf.sh load_generator 1 -d 1 -t 400000 In share mode manager: ./go.sh 0,1,2,3 0x1 0xF0 -s stdout -c load_generator : ./start_nf.sh load_generator 1 -d 1 -t 400000
-t argument just define how many pkts sent ,it will not shut down all the time in no share mode , unless using ctrl -c to stop it . But ,in share mode ,the load_generator could not run , no thing to pop out like this: In manager ,the NF has generator:
Anyway,i also use the commands : manager with ./go.sh 0,1,2,3 0x1 0xF0 -a 0x7f000000000 -s stdout -c and load_generator with ./go.sh 1 -d 1.It performances not run too.
Thanks! What branch are you using? We recently fixed the load_generator network function, but have not yet integrated the changes into the latest version of ONVM (master).
Thanks ! I have solved the problem. Now the load_generator network function works well.
We didn't call nf_setup before onvm_nflib_run, so segfault chaos ensued. See #164
Summary:
Added nf_setup before the onvm_nflib_run call banished the segfault. Test it by running manager with
./go.sh 0,1,2,3 3 0xF0 -a 0x7f000000000 -s stdout
and load_generator with./go.sh 1 -d 1
Should get this:Usage:
Merging notes:
TODO before merging :
Test Plan:
Run the manager and NF as described above
Review:
@kevindweb tiny change, just need a sanity check