diff options
Diffstat (limited to 'test_spec')
| -rwxr-xr-x | test_spec/vswitchperf_ltd.md | 75 |
1 files changed, 71 insertions, 4 deletions
diff --git a/test_spec/vswitchperf_ltd.md b/test_spec/vswitchperf_ltd.md index 07d49dc9..4aec9b80 100755 --- a/test_spec/vswitchperf_ltd.md +++ b/test_spec/vswitchperf_ltd.md @@ -808,7 +808,7 @@ The starting point for defining the suite of tests for benchmarking the performa **Description**: - The aim of this test is to characterize the ability of the DUT to process back-to-back frames. For each frame size previously defined under [Default Test Parameters](#DefaultParams), a burst of traffic is sent to the DUT with the minimum inter-frame gap between each frame. If the number of received frames equals the number of frames that were transmitted, the burst size should be increased and traffic is sent to the DUT again. The value measured is the back-to-back value, that is the maximum burst size the DUT can handle without any frame loss. + The aim of this test is to characterize the ability of the DUT to process back-to-back frames. For each frame size previously defined under [Default Test Parameters](#DefaultParams), a burst of traffic is sent to the DUT with the minimum inter-frame gap between each frame. If the number of received frames equals the number of frames that were transmitted, the burst size should be increased and traffic is sent to the DUT again. The value measured is the back-to-back value, that is the maximum burst size the DUT can handle without any frame loss. **Expected Result**: @@ -1103,13 +1103,24 @@ The starting point for defining the suite of tests for benchmarking the performa The aim of this test is to determine the maximum forwarding rate of the DUT when forwarding broadcast traffic. For each frame previously defined under [Default Test Parameters](#DefaultParams), the traffic should be set up as broadcast traffic. The traffic throughput of the DUT should be measured. + The test should be conducted with at least 4 physical ports on the DUT. The number of ports used MUST be recorded. + + As broadcast involves forwarding a single incoming packet to several destinations, the latency of a single packet is defined as the average of the latencies for each of the broadcast destinations. + + The incoming packet is transmitted on each of the other physical ports, it is not transmitted on the port on which it was received. The test MAY be conducted using different broadcasting ports to uncover any performance differences. + **Expected Result**: - **Metrics collected** + **Metrics collected**: The following are the metrics collected for this test: - The forwarding rate of the DUT when forwarding broadcast traffic. + - The minimum, average & maximum packets latencies observed. + + **Deployment scenario**: + + - Physical → virtual switch 3x physical. <br/> - #####Test ID: LTD.MemoryBandwidth.RFC2544.0PacketLoss.Scalability @@ -1149,13 +1160,19 @@ The starting point for defining the suite of tests for benchmarking the performa - #####Test ID: LTD.PacketLatency.InitialPacketProcessingLatency **Title**: Initial Packet Processing Latency - **Prerequisite Test**: N\A + **Prerequisite Test**: N\A **Priority**: **Description**: - In some virtual switch architectures, the first packets of a flow will take the system longer to process than subsequent packets in the flow. This test determines the latency for these packets. The test will measure the latency of the packets as they are processed by the flow-setup-path of the DUT. This test will send a single packet to the DUT after a fixed interval of time. The time interval will be equivalent to the amount of time it takes for a flow to time out in the virtual switch. Average packet latency will be determined over 1,000,000 packets. + In some virtual switch architectures, the first packets of a flow will take the system longer to process than subsequent packets in the flow. This test determines the latency for these packets. The test will measure the latency of the packets as they are processed by the flow-setup-path of the DUT. There are two methods for this test, a recommended method and a nalternative method that can be used if it is possible to disable the fastpath of the virtual switch. + + Recommended method: This test will send 64,000 packets to the DUT, each belonging to a different flow. Average packet latency will be determined over the 64,000 packets. + + Alternative method: This test will send a single packet to the DUT after a fixed interval of time. The time interval will be equivalent to the amount of time it takes for a flow to time out in the virtual switch plus 10%. Average packet latency will be determined over 1,000,000 packets. + + This test is intended only for non-learning switches; For learning switches use RFC2889. For this test, only unidirectional traffic is required. @@ -1237,6 +1254,56 @@ The starting point for defining the suite of tests for benchmarking the performa - The maximum number of frames per second that can be forwarded at the specified number of flows and the specified frame size, with zero packet loss. <br/> +---- +<a name="CPDPTests"></a> +#####2.3.5 Coupling between control path and datapath Tests + + The following tests aim to determine how tightly coupled the datapath and the control path are within a virtual switch. + + The following list is not exhaustive but should indicate the type of tests that should be required. It is expected that more will be added. + + - #####Test ID: LTD.CPDPCouplingFlowAddition + **Title**: Control Path and Datapath Coupling + + **Prerequisite Test**: + + **Priority**: + + **Description**: + + The aim of this test is to understand how exercising the DUT's control path affects datapath performance. + + Initially a certain number of flow table entries are installed in the vSwitch. Then over the duration of an RFC2544 throughput test flow-entries are added and removed at the rates specified below. No traffic is 'hitting' these flow-entries, they are simply added and removed. + + The test MUST be repeated with the following initial number of flow-entries installed: + - < 10 + - 1000 + - 100,000 + - 10,000,000 (or the maximum supported number of flow-entries) + + The test MUST be repeated with the following rates of flow-entry addition and deletion per second: + - 0 + - 1 (i.e. 1 addition plus 1 deletion) + - 100 + - 10,000 + + **Expected Result**: + + **Metrics Collected**: + + The following are the metrics collected for this test: + + - The maximum forwarding rate in Frames Per Second (FPS) and Mbps of the DUT. + - The average latency of the traffic flow when passing through the DUT (if testing for latency, note that this average is different from the test specified in Section 26.3 of [RFC2544]). + - CPU and memory utilization may also be collected as part of this test, to determine the vSwitch's performance footprint on the system. + + **Deployment scenario**: + + - Physical → virtual switch → physical. + + +<br/> + <a name="SummaryList"></a> ####2.3.9 Summary List of Tests |