Comments inline…
From: "Liew, Irene" <irene.l...@intel.com> Date: Tuesday, February 28, 2017 at 10:25 AM To: Thomas F Herbert <therb...@redhat.com>, "csit-...@lists.fd.io" <csit-...@lists.fd.io>, "Maciek Konstantynowicz (mkonstan)" <mkons...@cisco.com> Cc: vpp-dev <vpp-dev@lists.fd.io>, "Pierre Pfister (ppfister)" <ppfis...@cisco.com>, "Alec Hothan (ahothan)" <ahot...@cisco.com>, Karl Rister <kris...@redhat.com>, Douglas Shakshober <dsh...@redhat.com>, Andrew Theurer <atheu...@redhat.com>, "Liew, Irene" <irene.l...@intel.com> Subject: RE: fd.io CSIT vhost-user test scenario implementation priorities Here are my thoughts and comments on the topologies/test and workloads for CSIT vhost-user test scenarios. Pls refer to my comments inline below. -----Original Message----- From: Thomas F Herbert [mailto:therb...@redhat.com] Sent: Monday, February 27, 2017 10:04 AM To: csit-...@lists.fd.io<mailto:csit-...@lists.fd.io>; Maciek Konstantynowicz (mkonstan) <mkons...@cisco.com<mailto:mkons...@cisco.com>> Cc: vpp-dev <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>; Liew, Irene <irene.l...@intel.com<mailto:irene.l...@intel.com>>; Pierre Pfister (ppfister) <ppfis...@cisco.com<mailto:ppfis...@cisco.com>>; Alec Hothan (ahothan) <ahot...@cisco.com<mailto:ahot...@cisco.com>>; Karl Rister <kris...@redhat.com<mailto:kris...@redhat.com>>; Douglas Shakshober <dsh...@redhat.com<mailto:dsh...@redhat.com>>; Andrew Theurer <atheu...@redhat.com<mailto:atheu...@redhat.com>> Subject: fd.io CSIT vhost-user test scenario implementation priorities Please weigh in: We are starting to plan fd.io CSIT Vhost-user test scenario priorities for implementation in 17.04 and in 17.07 CSIT releases. Vhost-user performance is critical for VNF acceptance in potential use cases for VPP/fd.io adaption. We had previous email thread here: https://lists.fd.io/pipermail/csit-dev/2016-November/001192.html along with a TWS https://wiki.fd.io/view/TWS meetings on 12/02/16 and 12/07/16 summarized in this wiki: https://wiki.fd.io/view/CSIT/vhostuser_test_scenarios Topologies and tests Current in 17.01: 10ge2p1x520-dot1q-l2bdbasemaclrn-eth-2vhost-1vm 10ge2p1x520-dot1q-l2xcbase-eth-2vhost-1vm 10ge2p1x520-ethip4-ip4base-eth-2vhost-1vm 10ge2p1x520-ethip4vxlan-l2bdbasemaclrn-eth-2vhost-1vm 10ge2p1x520-eth-l2bdbasemaclrn-eth-2vhost-1vm 10ge2p1x520-eth-l2xcbase-eth-2vhost-1vm 10ge2p1x710-eth-l2bdbasemaclrn-eth-2vhost-1vm 40ge2p1xl710-eth-l2bdbasemaclrn-eth-2vhost-1vm single and multi-queue testing of pmd baseline Proposed in links above 1p1nic-dot1q-l2bdbase-eth-2vhost-1vm 1p1nic-ethip4vxlan-l2bdbase-eth-2vhost-1vm 1p1nic-dot1q-l2bdbase-eth-4vhost-2vm-chain 1p1nic-ethip4vxlan-l2bdbase-eth-4vhost-2vm-chain 1p1nic-dot1q-l2bdbase-eth-2vhost-1vm-chain-2nodes 1p1nic-ethip4vxlan-l2bdbase-eth-2vhost-1vm-2nodes [Irene] For the baseline testing on vhost-user, I would recommend to run core scaling from 1 core - max cores for 1 VM Phy-VM-Phy and 2 VMs PVVP. I know the current VPP v17.01 did not have the support to manually assign the vhost-user ports RXQ to specific cores to ensure load balancing across the cores. And from our experience in the lab, when I ran 3-core of work threads in 4vhost-2vm PVVP configuration, I observed the ports were unevenly distributed across 3 worker threads and VPP vNet suffered in performance scalability. If the manual RXQ assignment for vhost-user port feature will be made available in the next 17.04 or 17.07 release, I strongly propose to include the core scaling of worker threads in order to evaluate the vhost-user RXQ core assignment feature. For example, we can pick 1 test case of 2 vhost-1vm and run with configuration of 1-core, 2-core and 4-core of worker threads. We then pick 1 test case of 4vhost-2vm-chain and run with configuration of 1-core, 2-core, 3-core, 4-core and 6-core of worker threads. To limit the number of test I suggest we use 1,2,4 physical cores. I don’t think there will be many deployments with 6 or more physical cores for the vswitch (but I’m only talking about openstack-NFV deployments). One interesting variation is to test with hyper-thread and without: no hyper-thread = 1,2,4 VPP worker threads (mapped on as many full phys cores), with hyper-thread = 2,4,8 worker threads using sibling native threads) and check if we can find the same kind of linearity as Karl Rister (if you missed the other email thread. Proposed topologies for OpenStack from links above: 2p1nic-dot1q-l2bdscale-<n>flows-eth-<m>vhost-<o>vm-chain 2p1nic-ethip4vxlan-l2bdscale-<n>flows-eth-<m>vhost-<o>vm-chain New scenarios Proposed: Primary Overlay vxlan and VTEP 2p1nic-ethip4vxlan-l2bdbase-eth-2vhost-1vm 2p1nic-ethip4vxlan-l2bdbase-eth-20vhost-10vm [Irene] There is a trend in the industry using IPv6 over VXLAN. Shall we include IPv6 VXLAN scenario too? Do you mean IPv6 inside VxLAN tunnels or VxLAN tunnels using IPv6 UDP addresses? The term ethip4vxlan means VxLAN tunnels using IPv4 UDP addresses. I’m not sure many people are using IPv6 for the VxLAN overlay itself. MPLS over Ethernet Scaling Multiple VMs 2p1nic-dot1q-l2bdbase-eth-20vhost-10vm Workloads: VNF based on Linux relying kernel virtio driver - kernel linux bridge, kernel L3/IPv4 routing IPv4/v6 VPP vRouter [Irene] For the VNF workloads, we need to brainstorm and include real workload applications to test to provide a better understanding in performance for real NFV/SDN deployment. Yes these workloads listed above would be a good baseline number. I suggest we should start to brainstorm and discuss for other real representative workload for the Telco/datacenter deployment which we can later incorporate into CSIT. For example, some of the workloads that can be a good candidate are IPSec, Firewall, webserver SSL, etc. Did you check with the NSB work by Intel NPG/DCG (what is being committed to OPNFV/Yardstick)? This looks a lot like what they want to do. Thanks Alec Did I leave out anything? ... -- *Thomas F Herbert* SDN Group Office of Technology *Red Hat*
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
