Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default CPU Cores for Manager #219

Merged
merged 26 commits into from
Jul 22, 2020

Conversation

EthanBaron14
Copy link
Contributor

@EthanBaron14 EthanBaron14 commented Jun 5, 2020

New syntax for running the manager script.

Summary:

Implemented the improvements outlined in Issue #190.

When running the manager, users no longer have to input manager cores, a port mask, and a set of NF cores using positional arguments in the go.sh script. This functionality was retained, but from here on out we'll be suggesting that users use a new syntax with flags. In this PR, I added three flags: -m, -k, and -n, which set the cores for the manager to run on, the hexadecimal port mask, and the cores for the NF to run on in a hexadecimal port mask, respectively. The new go.sh syntax is as follows:

./go.sh -k <port mask> -n <NF core mask> [OPTIONS]

Users have the option to manually set at least three cores to use with the manager, using either -m or the legacy positional option syntax. There is no upper bound on the number of cores that the manager can use, but we require at least three.

Users will also be warned if their manager and NF cores overlap, regardless of the script running syntax they choose to use, because overlapping cores could cause some issues. Users will also see a message if they are using the default cores 0, 1 and 2 if they do not set the -m flag.

When a user opts to use the new syntax, they are required to specify -k and -n flags to set the port and NF core masks. This is because there is no intuitive default for these values. If a user instead decides to use a combination of the legacy and new methods and includes one of the new flags, the manager will not run, because we would have conflicting information specified in multiple places.

For any input arguments now, the script will do minor syntax checking with regular expressions. This will give more intuitive error messages if the user mistakenly enters bad input arguments.

Usage:

  • Adjusting required parameters for manager to enable default manager cores 0,1,2
  • New flags: -m <cores, separated by commas>, -k <port mask>, -n <NF core mask>
  • New syntax: ./go.sh -k <port mask> -n <NF core mask> [OPTIONS]
This PR includes
Resolves issues #190
Breaking API changes
Internal API changes
Usability improvements 👍
Bug fixes
New functionality
New NF/onvm_mgr args 👍
Changes to starting NFs
Dependency updates
Web stats updates

Merging notes:

  • Dependencies: bc

bc is a new dependency for openNetVM. It can be installed with

sudo apt-get install bc

TODO before merging :

  • PR is ready for review

Test Plan:

Tested running the manager with default cores, manually set cores, and various numbers of cores. Tested both legacy and new manager running syntax. Verified that user cannot use a combination of the syntax types. Verified that manager does not recognize new syntax as an attempt at running legacy syntax with improper arguments. Verified that regex correctly parses the input. Tested to see that warnings and dialogues are printed in the appropriate situations. Verified that changes to usage make sense and are formatted correctly.

Review:

@kevindweb - you wrote the bash script, I believe.

@onvm
Copy link

onvm commented Jun 5, 2020

In response to PR creation

CI Message

Aborting, need an authorized user to run CI

@EthanBaron14
Copy link
Contributor Author

@onvm test this. I know you didn't mean to reject me

@onvm
Copy link

onvm commented Jun 5, 2020

@onvm test this. I know you didn't mean to reject me

CI Message

Aborting, need an authorized user to run CI

@EthanBaron14
Copy link
Contributor Author

@onvm test pls

@onvm
Copy link

onvm commented Jun 5, 2020

@onvm test pls

CI Message

Aborting, need an authorized user to run CI

@EthanBaron14
Copy link
Contributor Author

@onvm i'm gonna cry please test this

@onvm
Copy link

onvm commented Jun 5, 2020

@onvm i'm gonna cry please test this

CI Message

Your results will arrive shortly

@onvm
Copy link

onvm commented Jun 5, 2020

@onvm i'm gonna cry please test this

CI Message

Error: Failed to parse Speed Tester stats

@EthanBaron14
Copy link
Contributor Author

That probably makes sense considering CI most likely is running the old go.sh syntax for the manager. This would need to be updated to run CI to test this. @kevindweb not sure how you want to proceed with this; we'll need to update it eventually regardless since the manager syntax is changing, I suppose.

@bdevierno1
Copy link
Contributor

bdevierno1 commented Jun 5, 2020

The current script used in CI will not work as the current usage will not function with your changes. Could you list the new usage so we can test this? Such as how do we configure what cores the manager will run? If this is the case you will also have to update the readme as the current guideline to run the manager will not work.

@EthanBaron14
Copy link
Contributor Author

The current script used in CI will not work as the current usage will not function with your changes. Could you list the new usage so we can test this? Such as how do we configure what cores the manager will run? If this is the case you will also have to update the readme as the current guideline to run the manager will not work.

That's all correct, like I said. Here's some of the notes I have, based on the new syntax:

  • Adjusting required parameters for manager to enable default manager cores 0,1,2
  • New flag: -m <cores, separated by commas>
  • New syntax: ./go.sh <port> <NF mask> [OPTIONS]

I think varying the number of arguments might cause inconsistency, but would love to get more opinions on this. Also difficult to know because bash requires us to know the number of arguments to shift the arguments to parse the flags inputted. Any input would be appreciated.

@EthanBaron14
Copy link
Contributor Author

I think I'm going to implement a version of Ben's solution with the goal of having something pushed by end-of-day. We can determine whether the first argument is the set of cores to use and shift the arguments accordingly. Might keep the -m flag as optional just to make it more intuitive for the user. This solution would preserve existing functionality but also simplify for new users or those who want to transition.

@EthanBaron14
Copy link
Contributor Author

EthanBaron14 commented Jun 5, 2020

Going to go a little further with this. The old syntax will still be allowed, e.g. ./go.sh <cores> <port mask> <NF cores> [OPTIONS] but a new syntax will be encouraged across the board:

./go.sh -k <port mask> -n <NF cores> [OPTIONS]

Note that the -m flag for setting the manager cores will remain optional and we will assume default cores 0,1,2 unless the flag is specified. The -k and -n flags for the port mask and NF cores will be required flags, since there isn't an easy default for those. The script will not run unless these flags are specified.

Users will have the option to either continue to use the old syntax (though this won't be supported or reflected anywhere in the docs except maybe a note for the manager), or adopt the new syntax where they are required to use -k and -n flags and optionally -m. Users will not be able to use both, though. Either a user uses the old syntax in its entirety, or uses the new syntax in its entirety. The implementation I have now with an optional set of manager cores will remain, but it won't be integrated into the old syntax. This will be exclusively used in the new syntax. Furthermore, attempting to use the old syntax but including the flags only used in the new syntax will raise an error and the script will not run.

The motivation for changing my approach to do it this way is so we can guarantee a level of backwards compatibility, but encourage proper practices going forward. Depending on whether users transition from the old to new syntax will dictate whether we phase out the old syntax at some point.

@EthanBaron14
Copy link
Contributor Author

Implemented flag syntax as mentioned above. Current syntax should now be referred to as legacy. New syntax for running manager go.sh script with cores 0,1,2, ports 0 and 1, and NFs on cores 3,4,5,6,7 should be:

./go.sh -k 3 -n 0xF8

For specifying manager cores, simply add the -m flag:

./go.sh -k 3 -n 0xF8 -m 0,1,2

Manager allows any number of cores greater than or equal than three. The manager checks the syntax of flag inputs as well as the legacy syntax. As stated above, users will have the option to either continue to use the old syntax (though this won't be supported or reflected anywhere in the docs except maybe a note for the manager), or adopt the new syntax where they are required to use -k and -n flags and optionally -m. Users will not be able to use both, though. Either a user uses the old syntax in its entirety, or uses the new syntax in its entirety. Attempting to use the old syntax but including the flags only used in the new syntax will raise an error and the script will not run.

Documentation has been updated to reflect the new syntax for the manager shell script as well as the added dependency of bc.

@EthanBaron14
Copy link
Contributor Author

@onvm test this

@onvm
Copy link

onvm commented Jun 5, 2020

@onvm test this

CI Message

Your results will arrive shortly

@onvm
Copy link

onvm commented Jun 5, 2020

@onvm test this

CI Message

Error: Failed to parse Speed Tester stats

@EthanBaron14
Copy link
Contributor Author

Was able to test successfully using legacy and new syntaxes. Tested with manager and speed test NF. Will continue to investigate CI failures with the goal of rectification within the next 24 hrs.

@bdevierno1
Copy link
Contributor

Screen Shot 2020-06-06 at 1 37 51 PM

This is the command CI runs

@EthanBaron14
Copy link
Contributor Author

EthanBaron14 commented Jun 6, 2020

Screen Shot 2020-06-06 at 1 37 51 PM

This is the command CI runs

Yup, that's working as intended. As we spoke about on Friday, bc is now a dependency. This is reflected in the documentation update commit on this branch as well as the error message you're seeing. If that's an issue on your machine, it could be an issue with CI. I'll check with Kevin in the morning. Thanks for bringing that up.

Also, regarding that readlink error you're seeing, that's likely a Mac-specific issue. Since we recommend running ONVM on Linux, that's not a problem. More information: http://biercoff.com/readlink-f-unrecognized-option-problem-solution-on-mac/

@bdevierno1
Copy link
Contributor

bdevierno1 commented Jun 6, 2020

Screen Shot 2020-06-06 at 1 37 51 PM This is the command CI runs

Yup, that's working as intended. As we spoke about on Friday, bc is now a dependency. This is reflected in the documentation update commit on this branch as well as the error message you're seeing. If that's an issue on your machine, it could be an issue with CI. I'll check with Kevin in the morning. Thanks for bringing that up.

Also, regarding that readlink error you're seeing, that's likely a Mac-specific issue. Since we recommend running ONVM on Linux, that's not a problem. More information: http://biercoff.com/readlink-f-unrecognized-option-problem-solution-on-mac/

Yeap sorry my bad I just wanted to show you the command CI uses. Also me just being dumb and not realizing my nimbnode lost connection..

@onvm
Copy link

onvm commented Jun 6, 2020

Test code from ethan

CI Message

Your results will arrive shortly

@EthanBaron14
Copy link
Contributor Author

@onvm

@onvm
Copy link

onvm commented Jun 24, 2020

@onvm

CI Message

Your results will arrive shortly

@EthanBaron14
Copy link
Contributor Author

Added some final changes that @kevindweb suggested. Ready for final review.

@onvm
Copy link

onvm commented Jun 24, 2020

@onvm

CI Message

Error: Failed to parse Speed Tester stats

@EthanBaron14
Copy link
Contributor Author

@onvm now

@onvm
Copy link

onvm commented Jun 24, 2020

@onvm now

CI Message

Your results will arrive shortly

onvm
onvm previously approved these changes Jun 24, 2020
Copy link

@onvm onvm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@onvm now

CI Message

Run successful see results:
Test took: 3 minutes, 56 seconds
✔️ Pktgen performance check passed
✔️ Speed Test performance check passed

[Results from nimbnode23]

  • Median TX pps for Pktgen: 7739866
    Performance rating - 100.52% (compared to 7700000 average)

  • Median TX pps for Speed Tester: 42254584
    Performance rating - 100.61% (compared to 42000000 average)

@EthanBaron14
Copy link
Contributor Author

@onvm last time

@onvm
Copy link

onvm commented Jun 24, 2020

@onvm last time

CI Message

Your results will arrive shortly

onvm
onvm previously approved these changes Jun 24, 2020
Copy link

@onvm onvm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@onvm last time

CI Message

Run successful see results:
Test took: 3 minutes, 55 seconds
✔️ Pktgen performance check passed
✔️ Speed Test performance check passed

[Results from nimbnode23]

  • Median TX pps for Pktgen: 7741782
    Performance rating - 100.54% (compared to 7700000 average)

  • Median TX pps for Speed Tester: 42105410
    Performance rating - 100.25% (compared to 42000000 average)

WilliamMaa
WilliamMaa previously approved these changes Jun 26, 2020
Copy link
Contributor

@WilliamMaa WilliamMaa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This all looks pretty good now, I think it's ready to merge if @kevindweb also approves this

kevindweb
kevindweb previously approved these changes Jun 27, 2020
Copy link
Contributor

@kevindweb kevindweb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@EthanBaron14 this looks solid to me, tons of necessary updates here!

@EthanBaron14 EthanBaron14 dismissed stale reviews from kevindweb, WilliamMaa, and onvm via 13e871b June 28, 2020 21:14
@EthanBaron14
Copy link
Contributor Author

@onvm verify I didn't break anything by updating readme's

@onvm
Copy link

onvm commented Jun 28, 2020

@onvm verify I didn't break anything by updating readme's

CI Message

Your results will arrive shortly

Copy link

@onvm onvm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@onvm verify I didn't break anything by updating readme's

CI Message

Run successful see results:
Test took: 4 minutes, 4 seconds
✔️ Pktgen performance check passed
✔️ Speed Test performance check passed

[Results from nimbnode23]

  • Median TX pps for Pktgen: 7737192
    Performance rating - 100.48% (compared to 7700000 average)

  • Median TX pps for Speed Tester: 42242943
    Performance rating - 100.58% (compared to 42000000 average)

@EthanBaron14
Copy link
Contributor Author

@kevindweb @WilliamMaa sorry I forgot to update one of the README.md files; can you guys review again?

Copy link
Contributor

@WilliamMaa WilliamMaa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems good now, @kevindweb for your approval.

Copy link
Contributor

@kevindweb kevindweb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doc updates look good

@dennisafa dennisafa merged commit f785f09 into sdnfv:develop Jul 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants