diff options
| -rw-r--r-- | src/dpdk/Makefile | 2 | ||||
| -rw-r--r-- | src/package-list.mk | 4 | ||||
| -rwxr-xr-x | systems/CentOS/build_base_machine.sh | 48 | ||||
| -rw-r--r-- | systems/README | 7 | ||||
| -rwxr-xr-x | systems/Ubuntu/build_base_machine.sh | 1 | ||||
| -rw-r--r-- | test_spec/vswitchperf_ltd.md | 123 |
6 files changed, 182 insertions, 3 deletions
diff --git a/src/dpdk/Makefile b/src/dpdk/Makefile index c6cc7bb1..4e99944b 100644 --- a/src/dpdk/Makefile +++ b/src/dpdk/Makefile @@ -62,6 +62,6 @@ $(WORK_DIR): $(TAG_DONE_FLAG): $(WORK_DIR) $(AT)cd $(WORK_DIR); git checkout $(DPDK_TAG) $(AT)sed -i 's/CONFIG_RTE_BUILD_COMBINE_LIBS=n/CONFIG_RTE_BUILD_COMBINE_LIBS=y/g' $(CONFIG_FILE) - # KNI was causing the 1.6.0 build to fail + $(AT)sed -i 's/CONFIG_RTE_LIBRTE_VHOST=n/CONFIG_RTE_LIBRTE_VHOST=y/g' $(CONFIG_FILE) $(AT)sed -i 's/CONFIG_RTE_LIBRTE_KNI=y /CONFIG_RTE_LIBRTE_KNI=n/g' $(CONFIG_FILE) $(AT)touch $@ diff --git a/src/package-list.mk b/src/package-list.mk index 0e64457b..0dbdbd29 100644 --- a/src/package-list.mk +++ b/src/package-list.mk @@ -6,8 +6,8 @@ # dpdk section # DPDK_URL ?= git://dpdk.org/dpdk DPDK_URL ?= http://dpdk.org/git/dpdk -DPDK_TAG ?= v1.6.0r0 +DPDK_TAG ?= v1.8.0 # OVS section OVS_URL ?= https://github.com/openvswitch/ovs -OVS_TAG ?= v2.3.1 +OVS_TAG ?= da79ce2b71dd879e7f20fdddc715568f6a74185a diff --git a/systems/CentOS/build_base_machine.sh b/systems/CentOS/build_base_machine.sh new file mode 100755 index 00000000..d08a80bd --- /dev/null +++ b/systems/CentOS/build_base_machine.sh @@ -0,0 +1,48 @@ +#!/bin/bash +# +# Build a base machine for CentOS distro +# +# Copyright 2015 OPNFV +# +# Licensed under the Apache License, Version 2.0 (the "License"); +# you may not use this file except in compliance with the License. +# You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. +# +# Contributors: +# Aihua Li, Huawei Technologies. + +# Synchronize package index files +yum -y update + +# this sould be installed if running from parent +yum -y install redhat-lsb + +# Make and Compilers +yum -y install make +yum -y install automake +yum -y install gcc +yum -y install libxml2 + +# tools +yum -y install curl +yum -y install autoconf libtool + +yum -y install libpcap-devel +yum -y install libnet + +# install gvim +yum -y install vim-X11 + +# install git-review tool, it is not as intuitive as expected +yum -y install epel-release +wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm +rpm -Uvh epel-release-7*.rpm +yum -y install git-review diff --git a/systems/README b/systems/README index 16ebc0c5..e9498600 100644 --- a/systems/README +++ b/systems/README @@ -1 +1,8 @@ This folder abstract out details among linux distros. + +One time setup: +--------------- + +On a freshly built system, run the following with a super user privilege + +./build_base_machine.sh diff --git a/systems/Ubuntu/build_base_machine.sh b/systems/Ubuntu/build_base_machine.sh index be1e25d5..a2b48a26 100755 --- a/systems/Ubuntu/build_base_machine.sh +++ b/systems/Ubuntu/build_base_machine.sh @@ -43,6 +43,7 @@ apt-get -y install libcurl4-openssl-dev apt-get -y install autoconf libtool apt-get -y install libpcap-dev apt-get -y install libglib2.0 +apt-get -y install libfuse-dev # Some useful tools you may optionally install #apt-get -y install ctags diff --git a/test_spec/vswitchperf_ltd.md b/test_spec/vswitchperf_ltd.md index f63a39e2..7cbbed2b 100644 --- a/test_spec/vswitchperf_ltd.md +++ b/test_spec/vswitchperf_ltd.md @@ -498,7 +498,9 @@ The following represents possible deployments which can help to determine the pe This test determines the DUT's maximum forwarding rate with X% traffic loss for a constant load (fixed length frames at a fixed interval time). The default loss percentages to be tested are: - X = 0% - X = 10^-7% + Note: Other values can be tested if required by the user. + The selected frame sizes are those previously defined under [Default Test Parameters](#DefaultParams). The test can also be used to determine the average latency of the traffic. Under the [RFC2544] test methodology, the test duration will include a number of trials; each trial should run for a minimum period of 60 seconds. A binary search methodology must be applied for each trial to obtain the final result. @@ -526,7 +528,9 @@ The following represents possible deployments which can help to determine the pe This test determines the DUT's maximum forwarding rate with X% traffic loss for a constant load (fixed length frames at a fixed interval time). The default loss percentages to be tested are: - X = 0% - X = 10^-7% + Note: Other values can be tested if required by the user. + The selected frame sizes are those previously defined under [Default Test Parameters](#DefaultParams). The test can also be used to determine the average latency of the traffic. Under the [RFC2544] test methodology, the test duration will include a number of trials; each trial should run for a minimum period of 60 seconds. A binary search methodology must be applied for each trial to obtain the final result. @@ -611,6 +615,125 @@ The following represents possible deployments which can help to determine the pe - Physical → virtual switch → physical. <br/> + - #####Test ID: LTD.Throughput.RFC2544.Soak + **Title**: RFC 2544 X% packet loss Throughput Soak Test + + **Prerequisite Test** LTD.Throughput.RFC2544.PacketLossRatio + + **Priority**: + + **Description**: + + The aim of this test is to understand the Throughput stability over an extended test duration in order to uncover any outliers. To allow for an extended test duration, the test should ideally run for 24 hours or, if this is not possible, for at least 6 hour. For this test, each frame size must be sent at the highest Throughput with X% packet loss, as determined in the prerequisite test. The default loss percentages to be tested are: + - X = 0% + - X = 10^-7% + + Note: Other values can be tested if required by the user. + + **Expected Result**: + + **Metrics Collected**: + + The following are the metrics collected for this test: + + - Throughput stability of the DUT. + - Any outliers in the Throughput stability. + - Any unexpected variation in Throughput stability. + +<br/> + + - #####Test ID: LTD.Throughput.RFC2544.SoakFrameModification + **Title**: RFC 2544 X% packet loss Throughput Soak Test with Frame Modification + + **Prerequisite Test** LTD.Throughput.RFC2544.PacketLossRatioFrameModification + + **Priority**: + + **Description**: + + The aim of this test is to understand the Throughput stability over an extended test duration in order to uncover any outliers. To allow for an extended test duration, the test should ideally run for 24 hours or, if this is not possible, for at least 6 hour. For this test, each frame size must be sent at the highest Throughput with X% packet loss, as determined in the prerequisite test. The default loss percentages to be tested are: + - X = 0% + - X = 10^-7% + + Note: Other values can be tested if required by the user. + + During this test, the DUT must perform the following operations on the traffic flow: + + - Perform packet parsing on the DUT's ingress port. + - Perform any relevant address look-ups on the DUT's ingress ports. + - Modify the packet header before forwarding the packet to the DUT's egress port. Packet modifications include: + - Modifying the Ethernet source or destination MAC address. + - Modifying/adding a VLAN tag. + - Modifying/adding a MPLS tag. + - Modifying the source or destination ip address. + - Modifying the TOS/DSCP field. + - Modifying the source or destination ports for UDP/TCP/SCTP (Recommended). + - Modifying the TTL. + + **Expected Result**: + + **Metrics Collected**: + + The following are the metrics collected for this test: + + - Throughput stability of the DUT. + - Any outliers in the Throughput stability. + - Any unexpected variation in Throughput stability. + +<br/> + + - #####Test ID: LTD.Throughput.RFC6201.ResetTime + **Title**: RFC 6201 Reset Time Test + + **Prerequisite Test**: N\A + + **Priority**: + + **Description**: + + The aim of this test is to determine the length of time it takes the DUT to recover from a reset. For each frame size previously defined under [Default Test Parameters](#DefaultParams), traffic should be sent to the DUT under normal conditions. During the duration of the test and while the traffic flows are passing through the DUT, the DUT should be reset and the Reset time measured. The Reset time is the total time that a device is determined to be out of operation and includes the time to perform the reset and the time to recover from it (cf. [RFC6201]) + + [RFC6201] defines two methods to measure the Reset time: + - Frame-Loss Method: which requires the monitoring of the number of lost frames and calculates the Reset time based on the number of frames lost and the offered rate according to the following formula: + <pre><code> + Frames_lost (packets) + Reset_time = ------------------------------------- + Offered_rate (packets per second) + </code></pre> + - Timestamp Method: which measures the time from which the last frame is forwarded from the DUT to the time the first frame is forwarded after the reset. This involves time-stamping all transmitted frames and recording the timestamp of the last frame that was received prior to the reset and also measuring the timestamp of the first frame that is received after the reset. The Reset time is the difference between these two timestamps. + + According to [RFC6201] the choice of method depends on the test tool's capability; the Frame-Loss method SHOULD be used if the test tool supports: + - Counting the number of lost frames per stream. + - Transmitting test frame despite the physical link status. + + whereas the Timestamp method SHOULD be used if the test tool supports: + - Timestamping each frame. + - Monitoring received frame's timestamp. + - Transmitting frames only if the physical link status is up. + + **Expected Result**: + + **Metrics collected** + + The following are the metrics collected for this test: + - Average Reset Time. + + Results of this test should include the following information: + - Throughput in Fps and Mbps. + - Average Frame Loss. + - Average Reset Time in milliseconds. + - Number of trials. + - Protocol: IPv4, IPv6, MPLS, etc. + - Frame Size in Octets + - Port Media: Ethernet, Gigabit Ethernet (GbE), etc. + - Port Speed: 10 Gbps, 40 Gbps etc. + - Interface Encapsulation: Ethernet, Ethernet VLAN, etc. + + **Deployment scenario**: + + - Physical → virtual switch → physical. + +<br/> [RFC1242]:(http://www.ietf.org/rfc/rfc1242.txt) [RFC2544]:(http://www.ietf.org/rfc/rfc2544.txt) [RFC5481]:(http://www.ietf.org/rfc/rfc5481.txt) |