Scaling Example NF Updates

[catherinemeadows]

Modified the Scaling Example NF to assign spawned children with the same service ID as the parent and updated the README with more detail about callback and advanced rings modes.

• addressed issue 250

Summary:

Usage:

This PR includes
Resolves issues	250
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: None

TODO before merging :

• PR is ready for review

Test Plan:

• tested NF in a chain (speed tester -> scaling -> basic monitor) to verify correct packet flow

[twood02]

@catherinemeadows
Can you remind me -- Is the idea of this NF that it spawns N child NFs all with the same service ID as the "main" NF that started initially. Packets are then distributed across the N+1 NFs. All of these NFs then forward packets to whatever destination ID was set on the command line.

Is this right? Or does the main NF not actually have a run loop so there are N nfs total receiving packets (only the children)?

[catherinemeadows]

@twood02 Yes, the parent NF spawns N children NFs with the same service ID and the packets are distributed across the N+1 NFs and forwarded to the destination ID. Should I add this to the documentation?

[twood02]

looks good to me

[twood02]

@NoahChinitzGWU can you build and run this code on one of your systems to verify it is working as expected? Post a screenshot/paste the output here

[NoahChinitz]

Manager:

Scaling NF Left Terminal, Monitor NF Right Terminal:

Does this seem correct, or should I be seeing 3 additional scaling NFs in the manager?

[catherinemeadows]

They should scale once you send packets to it (you can use speed tester)

[NoahChinitz]

Manager:

Works!

[NoahChinitz]

NFs used (scaling left, basic monitor middle, speed tester right)

[NoahChinitz]

See my previous comments for screenshots of working output

[twood02]

@dennisafa - can you do a very quick review and approve this if nothing jumps out at you?

[dennisafa]

Changes look good to me. Unrelated to the bug itself, I think it would make sense to do the scaling differently. Right now, we spawn the child NF's as soon as we receive a packet in the packet_handler_with_scaling() function. The new NF's packet handler is then set to packet_handler_fwd(). Why not spawn all of the child NF's upon startup, rather than wait for the first packet? The current implementation would make more sense if we were spawning the child NF's based on say, the packet count/rate.