Shared core functionality for messages

[dennisafa]

Adds functionality to sleep when no messages are enqueued onto an nf's message ring.

Summary:

This is functionality I implemented as part of the larger mTCP project, in which an NF constantly receives lots of messages. This works exactly the same way as sleeping on an empty packet ring.

Usage: Run the manager with shared CPU enabled.

This PR includes
Resolves issues
Breaking API changes
Internal API changes
Usability improvements
Bug fixes
New functionality	X
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:

Tested by sending a large influx of messages to an NF running in shared cpu mode. Also tested with multiple NF's on the same core. Checked htop CPU usage to verify proper sleeping when no messages were being sent.

Review:

Review checklist:

• Sanity checks, assigned to @koolzz @kevindweb

  • Run make in /onvm and /examples directories
  • Test the new functionality

• Code style, assigned to @koolzz @kevindweb

  • Run linter
  • Check everything style related

• Code design, assigned to @koolzz @kevindweb

  • Check for memory leaks
  • Check that code is reusable
  • Code is clean, functions are concise
  • Verify that edge cases properly handled

• Performance, assigned to @koolzz @kevindweb

  • Run Speed Tester NF, report performance.
  • Run pktgen, report performance (not really required)

• Documentation, assigned to @koolzz @kevindweb

  • Check if the new changes are well documented, in both code and READMEs

[onvm]

In response to PR creation

CI Message

Your results will arrive shortly

[onvm]

In response to PR creation

CI Message

Error: ERROR: Failed to fetch results from nimbnode30

[dennisafa]

@onvm try it now

[kevindweb]

@onvm can we pass this pktgen test?

[onvm]

@onvm can we pass this pktgen test?

CI Message

Your results will arrive shortly

[kevindweb]

Yay to CI! I tested on cloudlab and got 13422053pps for pktgen. 4573120 rx/tx for 2 speed testers together. I'll test the specific message functionality later, but basic performance looks solid

[kevindweb]

@onvm can we show dennis our new features?

[onvm]

@onvm can we show dennis our new features?

CI Message

Your results will arrive shortly

[kevindweb]

@dennisafa pktgen from CI will work if you merge develop into this branch

[koolzz]

@onvm perf?

[kevindweb]

@onvm perf

[onvm]

@onvm perf

CI Message

Your results will arrive shortly

[kevindweb]

@onvm i believe in you

[onvm]

@onvm i believe in you

CI Message

Your results will arrive shortly

[dennisafa]

@onvm how's it goin pktgen

[onvm]

@onvm how's it goin pktgen

CI Message

Your results will arrive shortly

[kevindweb]

@onvm if you fail I'll catch you now!

[onvm]

@onvm if you fail I'll catch you now!

CI Message

Your results will arrive shortly

[koolzz]

@dennisafa just add the https://github.com/sdnfv/openNetVM/pull/151/files changes into this pr

[dennisafa]

@dennisafa just add the https://github.com/sdnfv/openNetVM/pull/151/files changes into this pr

oops. got it.

[onvm]

Testing

CI Message

Your results will arrive shortly

[onvm]

Testing

CI Message

Error: Failed to parse Speed Tester stats

[onvm]

Testing

CI Message

Your results will arrive shortly

[dennisafa]

awesome, im excited CI has mTCP results now. no real performance benefit, just the fact that the semwait call is logically equivalent so having it in both dequeue_messages and dequeue_packets would be extra

On Thu, Jul 25, 2019 at 6:45 PM Kevin Deems notifications@github.com wrote:

@kevindweb approved this pull request.

Let's goooooooo! First successful mTCP CI run. I also have been testing on cloudlab, when I merged develop, and disabled flow table I got 14746136pps Pktgen, and 12895796pps with ft macro enabled, which is normal. Created a 4 speed tester chain with performance of ~17664647 pps tx on all 4, and got almost 52mil pps just running one speed_tester. Also, not a change request, just a question, was there a performance benefit to moving this code out of onvm_nflib_dequeue_packets, or did it just make more logical sense? I ask this because there doesn't seem to be a whole lot changed, except for the condition definition.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sdnfv/openNetVM/pull/149?email_source=notifications&email_token=AH3EIZW6GDMOG5PBQUKBPTTQBIUJ7A5CNFSM4H3KRXKKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOB7UOMZY#pullrequestreview-266921575, or mute the thread https://github.com/notifications/unsubscribe-auth/AH3EIZTUNKSZLJL325TGXLTQBIUJ7ANCNFSM4H3KRXKA .