Versions Compared

Old Version 2

changes.mady.by.user Sridhar Rao

Saved on

compared with

New Version Current

changes.mady.by.user Daniele Zulberti

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Sl. No

Topic

Presenters

Notes

1

Development Update


Epic-VINEPERF-672:Create Tools as part of moselle release
Epic-VINEPERF-671:Add support for newer software versions
Epic-VINEPERF-670:Create clean workflows for Baremetal, Openstack and Kubernetes Usecases
Epic-VINEPERF-669:Improve Stability for moselle Release
Epic-VINEPERF-652:Enhance XTesting-ViNePerf Integration
Task-VINEPERF-658:Enhance framework for XTesting-K8s Usecase
Task-VINEPERF-654:XTesting-ViNePerf Integration Enhancement - Kubernetes
Task-VINEPERF-653:XTesting-ViNePerf Enhancement - Openstack
Epic-VINEPERF-638:Dataplane performance testing for various internal (within cloud) scenarios
Task-VINEPERF-643:Pod-Pod Communication

Daniele Zulberti to submit patch - reference deployment and config files (pod/nad), prox&trex.

2.Discussion of the results

Summary :

  1. VPP performs better than OVS.
  2. Prox performs better than T-Rex
  3. Bi-Directional Prox is more inconsistent (throughput) than unidirectional
  4. Trex results are not consistent.
  5. Increasing hops, even with single node, affects the performance.  Better summary for varying topologies
  6. Prox has some limitations - mainly w.r.t core assignments - which affects the performance.


  1. VPP performs better than OVS
    1. Bad OVS config?
  2. Prox performs better than T-Rex
    1. Bad support for Trex execution in container?
    2. Bad resource allocation for Trex? few cores used?
  3. Bi-Directional Prox is more inconsistent (throughput) than unidirectional
    1. Small queues for managing small packet sizes?
  4. Trex results are not consistent.
    1. See point 2
  5. Increasing hops, even with single node, affects the performance.
    1. From PROX+VPP we can see that the latency is the most affected stat.
    2. For the other cases this could not be the major problem but just a side effect.
  6. Prox has some limitations
    1. Can’t increase core higher than 1 for each Prox’s task - which affects the performance. (Is more research needed? Is it a configuration issue? Is it related to the container version of PROX?)
  7. Trex has some limitations
    1. bidirectional traffic only (tried only with memif)
    2. driver net_virtio_user is not supported (No OVS testing)
3.Limitation of L3

Any of these two (red and green) paths even possible without manually adding routes/flows?

Using IP-address is easy with iperf/netperf. Whereas, a Tgen (Prox/Trex), with DPDK-interfaces, it gets difficult.

Not sure if our IPAM configurations are correct - Working on finding the right configuration (if any).

How Userspace CNI handles IPAM configuration is not clear - with VPP, we didn't see any routes getting added.

Reach out to Luc/Yuri - to check if they have achieved this with Prox. Maybe, Prox-L3swap mode can respond to ARPs.

https://doc.dpdk.org/api/examples_2bond_2main_8c-example.html

...