-
Notifications
You must be signed in to change notification settings - Fork 136
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
Bug fix: Flow Directory. (test_flow_dir) #248
base: develop
Are you sure you want to change the base?
Conversation
CI MessageYour results will arrive shortly |
CI MessageError: Failed to parse Pktgen stats |
@onvm Hello HAL, do you read me? |
CI MessageYour results will arrive shortly |
CI MessageError: Failed to fetch results from nimbnode23 |
In my last commit I have added a new feature/example populating service chains to the flow table #60 . You can then use this to test the onvm flow dir API by starting up up to four test_flow_dir NFs. Another way is to run this NF to populate the flow table then subsequently use the simple forward NF; but first modifying the packet handler to use the action next instead. I have made further changes to the flow table api as it was printing the keys I had pre-defined backwards. I have reverted the flow_entry variable to initialize to NULL. However, I had to allocate memory within the packet handler which will probably be slower. I will update this soon as there is probably a better way to do this. |
@onvm Hello HAL, do you read me? |
CI MessageYour results will arrive shortly |
1 similar comment
CI MessageYour results will arrive shortly |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@onvm Hello HAL, do you read me
CI Message
Run successful see results:
Test took: 14 minutes, 59 seconds
✔️ Pktgen performance check passed
❌ PR drops Speed Test performance below minimum requirement
[Results from nimbnode23]
-
Median TX pps for Pktgen: 7735755
Performance rating - 100.46% (compared to 7700000 average) -
Median TX pps for Speed Tester: 39947208
Performance rating - 95.11% (compared to 42000000 average)
@onvm is it really slow? |
CI MessageYour results will arrive shortly |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@onvm is it really slow?
CI Message
Run successful see results:
Test took: 4 minutes, 1 second
✔️ Pktgen performance check passed
❌ PR drops Speed Test performance below minimum requirement
[Results from nimbnode23]
-
Median TX pps for Pktgen: 7733636
Performance rating - 100.44% (compared to 7700000 average) -
Median TX pps for Speed Tester: 39891946
Performance rating - 94.98% (compared to 42000000 average)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see comment
onvm/onvm_nflib/onvm_pkt_common.c
Outdated
@@ -102,7 +102,7 @@ onvm_pkt_process_tx_batch(struct queue_mgr *tx_mgr, struct rte_mbuf *pkts[], uin | |||
// and !<return value> is 1. | |||
nf->stats.act_drop++; | |||
nf->stats.tx += !onvm_pkt_drop(pkts[i]); | |||
} else if (meta->action == ONVM_NF_ACTION_NEXT) { | |||
} else if (meta->action == ONVM_NF_ACTION_NEXT || meta->destination == 255) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No magic numbers please, what is this 255? Why do we need it?
Can't the packet just set action ONVM_NF_ACTION_NEXT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having a special number is purposeful since we want to use this to indicate the next action even if the NF wasn't designed for that purpose (eg this lets us make the SimpleFwd NF use the "next action" behavior if you set 255 at the command line as the destination ID).
But you are right that it shouldn't be totally magic -- @bdevierno1 you should #define a constant somewhere for this instead of using 255 directly here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, feels like a lazy way to change the action(we could just bake in the same if meta->destination ==255 -> meta->action = ONVM_NF_ACTION_NEXT
into the NF itself) but if people find it easier lets define a global const.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bdevierno1 Also if we're doing this, after #defining the constant (probably in common.h) do a onvm mgr startup check to confirm that your const number is more than MAX_NFS. Otherwise if someone has 512 NFS configured they will be suprised that forwarding to 256 doesn't work
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line was resulting in the perf drop with speed tester. I couldn't find another way to optimize this besides moving the ONVM_NF_ACTION_TONF if statement above the one for the NEXT action on line 105. But I think this would feel like it would be an over-optimization for speed tester? I'll update to use the global const for now. I could also update all the sample NFs to use a flag instead to indicate to use the next action as well if we decide that's better.
@onvm Test please. |
CI MessageYour results will arrive shortly |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@onvm Test please.
CI Message
Run successful see results:
Test took: 4 minutes, 3 seconds
✔️ Pktgen performance check passed
❌ PR drops Speed Test performance below minimum requirement
[Results from nimbnode23]
-
Median TX pps for Pktgen: 7732411
Performance rating - 100.42% (compared to 7700000 average) -
Median TX pps for Speed Tester: 39828650
Performance rating - 94.83% (compared to 42000000 average)
} else if (meta->action == ONVM_NF_ACTION_NEXT) { | ||
/* TODO: Here we drop the packet : there will be a flow table | ||
in the future to know what to do with the packet next */ | ||
} else if (meta->action == ONVM_NF_ACTION_NEXT || meta->destination == ACTION_NEXT_DEST_ID) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bdevierno1 setting 255 as the next action would definitely decrease performance, but I think that (from CI) we see that just having to process this or ||
statement in the condition slows down other NFs. Because we know that speed_tester would not have set the meta->destination
to 255. I think that's the cause of the ~4% performance drop from CI
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this is correct. Unfortunately, I tried different ways to optimize this but did not see any substantial improvements. By removing the OR I will still have to set another conditional which will have to be placed before this statement so as to maintain the same logic. Perhaps there is another way to do this?
Test flow directory NF bug fix.
Summary:
NF was crashing when attempting to add a new rule to the shared sdn_nf flow table.
Usage:
As described in readme.
Merging notes:
TODO before merging :
This resolves issue #247
Test Plan:
Run NF with Pktgen. Test that NF does not crash as before. As I made a change to the fill key functionality. All NFs that add/remove/lookup keys to a flow table need to be tested.
Review:
Anyone.