Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
vrouter-dpdk performance optimization blueprint
Partial-bug: #1767047 Change-Id: I201ec2000e9fd62a90246e18eab4999b90bd1aeb Signed-off-by: Yi Yang <yi.y.yang@intel.com>
- Loading branch information
Showing
1 changed file
with
54 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,54 @@ | ||
|
||
#1. Introduction | ||
Optimize contrail-vrouter-dpdk performance by batch processing and caching | ||
|
||
#2. Problem statement | ||
We use vtune and perf to find some hotspots, vr_htable_find_hentry is the biggest hotspot, htable | ||
implementation is not so efficient, we also find vrouter doesn't use batch processing, these are main | ||
factors impacting on contrail-vrouter-dpdk performance. | ||
|
||
#3. Proposed solution | ||
We propose to use caching and batch processing to boost performance, we have implemented a prototype for this, performance tuning is ongoing. | ||
|
||
#4. Implementation | ||
##4.1 Use hash table to cache flow table lookup result | ||
Use a big array to cache flow table lookup results, flow key hash value is used as hash index, flow | ||
entry pointer is saved in this array to check if there is a hash collision, the old one will be evicted | ||
if yes, the new one is saved, otherwise the flow is allowed to forward, so remove expensive flow table lookup overhead, we have implemented a prototype for this, performance tuning is ongoing. | ||
|
||
##4.3 Do batch processing for vrouter Rx path | ||
Many projects have proved batch processing is the best way to boost performance because it can make full | ||
use of cache locality and prefetch, we have implemented a prototype for this, performance tuning is ongoing. | ||
|
||
#5. Performance and scaling impact | ||
##5.1 API and control plane | ||
No Impact | ||
|
||
##5.2 Forwarding performance | ||
We expect this solution can boost forwarding performance. | ||
|
||
#6. Upgrade | ||
No Impact | ||
|
||
#7. Deprecations | ||
None | ||
|
||
#8. Dependencies | ||
None | ||
|
||
#9. Testing | ||
##9.1 Unit tests | ||
None | ||
##9.2 Dev tests | ||
During Dev phase the developer should test the creation of the new queue for control messages and run | ||
some basic benchmarks to confirm performance improvement. | ||
##9.3 System tests | ||
At system level a full setup with bonding driver should be put in place and verify the stability and | ||
performance gain of the system. | ||
|
||
#10. Documentation Impact | ||
None | ||
|
||
#11. References | ||
None | ||
|