Hi Karl Can you also tell which version of DPDK you were using for OVS and for VPP (for VPP is it the one bundled with 17.01?).
“The pps is the bi-directional sum of the packets received back at the traffic generator.” Just to make sure…. If your traffic gen sends 1 Mpps to each of the 2 interfaces and you get no drop (meaning you receive 1 Mpps from each interface). What do you report? 2 Mpps or 4 Mpps? You seem to say 2Mpps (sum of all RX). The CSIT perf numbers report the sum(TX) = in the above example CSIT reports 2 Mpps. The CSIT numbers for 1 vhost/1 VM (practically similar to yours) are at about half of what you report. https://docs.fd.io/csit/rls1701/report/vpp_performance_results_hw/performance_results_hw.html#ge2p1x520-dot1q-l2xcbase-eth-2vhost-1vm-ndrpdrdisc scroll down the table to tc13 tc14, 4t4c (4 threads) L2XC, 64B NDR, 5.95Mpps (aggregated TX of the 2 interfaces) PDR 7.47Mpps. while the results in your slides put it at around 11Mpps. So either your testbed really switches 2 times more packets than the CSIT one, or you’re actually reporting double the amount compared to how CSIT reports it… Thanks Alec From: Karl Rister <kris...@redhat.com> Organization: Red Hat Reply-To: "kris...@redhat.com" <kris...@redhat.com> Date: Thursday, February 16, 2017 at 11:09 AM To: "Alec Hothan (ahothan)" <ahot...@cisco.com>, "Maciek Konstantynowicz (mkonstan)" <mkons...@cisco.com>, Thomas F Herbert <therb...@redhat.com> Cc: Andrew Theurer <atheu...@redhat.com>, Douglas Shakshober <dsh...@redhat.com>, "csit-...@lists.fd.io" <csit-...@lists.fd.io>, vpp-dev <vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] Interesting perf test results from Red Hat's test team On 02/15/2017 08:58 PM, Alec Hothan (ahothan) wrote: Great summary slides Karl, I have a few more questions on the slides. · Did you use OSP10/OSPD/ML2 to deploy your testpmd VM/configure the vswitch or is it direct launch using libvirt and direct config of the vswitches? (this is a bit related to Maciek’s question on the exact interface configs in the vswitch) There was no use of OSP in these tests, the guest is launched via libvirt and the vswitches are manually launched and configured with shell scripts. · Unclear if all the charts results were measured using 4 phys cores (no HT) or 2 phys cores (4 threads with HT) Only the slide 3 has any 4 core (no HT) data, all other data is captured using HT on the appropriate number of cores: 2 for single queue, 4 for two queue, and 6 for three queue. · How do you report your pps? ;-) Are those o vswitch centric (how many packets the vswitch forwards per second coming from traffic gen and from VMs) o or traffic gen centric aggregated TX (how many pps are sent by the traffic gen on both interfaces) o or traffic gen centric aggregated TX+RX (how many pps are sent and received by the traffic gen on both interfaces) The pps is the bi-directional sum of the packets received back at the traffic generator. · From the numbers shown, it looks like it is the first or the last · Unidirectional or symmetric bi-directional traffic? symmetric bi-directional · BIOS Turbo boost enabled or disabled? disabled · How many vcpus running the testpmd VM? 3, 5, or 7. 1 VCPU for house keeping and then 2 VCPUs for each queue configuration. Only the required VCPUs are active for any configuration, so the VCPU count varies depending on the configuration being tested. · How do you range the combinations in your 1M flows src/dest MAC? I’m not aware about any real NFV cloud deployment/VNF that handles that type of flow pattern, do you? We increment all the fields being modified by one for each packet until we hit a million and then we restart at the base value and repeat. So all IPs and/or MACs get modified in unison. We actually arrived at the srcMac,dstMac configuration in a backwards manner. On one of our systems where we develop the traffic generator we were getting an error when doing srcMac,dstMac,srcIp,dstIp that we couldn't figure out in the time needed for this work so we were going to just go with srcMac,dstMac due to time constraints. However, on the system where we actually did the testing both worked so I just collected both out of curiosity. Thanks Alec *From: *<vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io>> on behalf of "Maciek Konstantynowicz (mkonstan)" <mkons...@cisco.com<mailto:mkons...@cisco.com>> *Date: *Wednesday, February 15, 2017 at 1:28 PM *To: *Thomas F Herbert <therb...@redhat.com<mailto:therb...@redhat.com>> *Cc: *Andrew Theurer <atheu...@redhat.com<mailto:atheu...@redhat.com>>, Douglas Shakshober <dsh...@redhat.com<mailto:dsh...@redhat.com>>, "csit-...@lists.fd.io<mailto:csit-...@lists.fd.io>" <csit-...@lists.fd.io<mailto:csit-...@lists.fd.io>>, vpp-dev <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>, Karl Rister <kris...@redhat.com<mailto:kris...@redhat.com>> *Subject: *Re: [vpp-dev] Interesting perf test results from Red Hat's test team Thomas, many thanks for sending this. Few comments and questions after reading the slides: 1. s3 clarification - host and data plane thread setup - vswitch pmd (data plane) thread placement a. "1PMD/core (4 core)” - HT (SMT) disabled, 4 phy cores used for vswitch, each with data plane thread. b. “2PMD/core (2 core)” - HT (SMT) enabled, 2 phy cores, 4 logical cores used for vswitch, each with data plane thread. c. in both cases each data plane thread handling a single interface - 2* physical, 2* vhost => 4 threads, all busy. d. in both cases frames are dropped by vswitch or in vring due to vswitch not keeping up - IOW testpmd in kvm guest is not DUT. 2. s3 question - vswitch setup - it is unclear what is the forwarding mode of each vswitch, as only srcIp changed in flows a. flow or MAC learning mode? b. port to port crossconnect? 3. s3 comment - host and data plane thread setup a. “2PMD/core (2 core)” case - thread placement may yield different results - physical interface threads as siblings vs. - physical and virtual interface threads as siblings. b. "1PMD/core (4 core)” - one would expect these to be much higher than “2PMD/core (2 core)” - speculation: possibly due to "instruction load" imbalance between threads. - two types of thread with different "instruction load": phy->vhost vs. vhost->phy - "instruction load" = instr/pkt, instr/cycle (IPC efficiency). 4. s4 comment - results look as expected for vpp 5. s5 question - unclear why throughput doubled a. e.g. for vpp from "11.16 Mpps" to "22.03 Mpps" b. if only queues increased, and cpu resources did not, or have they? 6. s6 question - similar to point 5. - unclear cpu and thread reasources. 7. s7 comment - anomaly for 3q (virtio multi-queue) for (srcMAc,dstMAC) a. could be due to flow hashing inefficiency. -Maciek On 15 Feb 2017, at 17:34, Thomas F Herbert <therb...@redhat.com<mailto:therb...@redhat.com> <mailto:therb...@redhat.com><mailto:therb...@redhat.com%3e>> wrote: Here are test results on VPP 17.01 compared with OVS/DPDK 2.6/1611 performed by Karl Rister of Red Hat. This is PVP testing with 1, 2 and 3 queues. It is an interesting comparison with the CSIT results. Of particular interest is the drop off on the 3 queue results. --TFH -- *Thomas F Herbert* SDN Group Office of Technology *Red Hat* <vpp-17.01_vs_ovs-2.6.pdf>_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> <mailto:vpp-dev@lists.fd.io> https://lists.fd.io/mailman/listinfo/vpp-dev -- Karl Rister <kris...@redhat.com<mailto:kris...@redhat.com>>
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
