This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
wiki:ltd_test_spec_overview [2015/10/08 14:49] Al Morton [LTD Test Spec Overview] |
wiki:ltd_test_spec_overview [2015/12/15 23:04] (current) Al Morton [LTD Test Spec Overview] |
||
---|---|---|---|
Line 3: | Line 3: | ||
(This page is currently Under Construction, but now describes all tests as of Sept 17, 2015) | (This page is currently Under Construction, but now describes all tests as of Sept 17, 2015) | ||
- | The Level Test Design (LTD) Specification is one of the products of the OPNFV vsperf project. This page provides an overview of the LTD spec in several forms. | + | The Level Test Design (LTD) Specification is one of the products of the OPNFV vsperf project. The LTD spec is formatted in ReStructured Text (RST), and presented in HTML form with the project [[http://artifacts.opnfv.org/vswitchperf/docs/test_spec/vswitchperf_ltd.html |Artifacts]]. This wiki page provides an overview of the LTD spec in several forms: |
- | - The LTD Spec and its goals are Summarized in a 20 page [[https://tools.ietf.org/html/draft-vsperf-bmwg-vswitch-opnfv-00|Internet Draft ]] | + | - The LTD Spec and its goals are Summarized in a 21 page [[https://tools.ietf.org/html/draft-vsperf-bmwg-vswitch-opnfv-01|Internet Draft ]] |
- Short descriptions of each of the tests in the LTD Spec (below) | - Short descriptions of each of the tests in the LTD Spec (below) | ||
- Example Device Under Test (DUT) Set-ups, called Deployment Scenarios at [[https://wiki.opnfv.org/vsperf/test_methodology|Test Methodology ]] page. | - Example Device Under Test (DUT) Set-ups, called Deployment Scenarios at [[https://wiki.opnfv.org/vsperf/test_methodology|Test Methodology ]] page. | ||
+ | |||
+ | The approach VSPERF has adopted is to take existing tests that are relevant to performance benchmarking of physical switches, and applying them to benchmarking virtual switches (this is to allow for a fair comparison with their physical counterparts). Once this is done, tests that are relevant to benchmarking virtual switches only, will be developed. | ||
===== List of Tests and Descriptions ===== | ===== List of Tests and Descriptions ===== | ||
Line 12: | Line 14: | ||
=== Speed of Activation === | === Speed of Activation === | ||
- | o Throughput.RFC2889.AddressLearningRate | + | o Activation.RFC2889.AddressLearningRate |
This test measures the address learning rate of the DUT, in accordance with [[https://tools.ietf.org/html/rfc2889#section-5.8 |section 5.8 of RFC 2889]]. A minimum of 3 DUT ports are required for this test, a learning port where frames first arrive at the DUT, a test port where frames are forwarded and returned to the source, and a monitoring port where the test device listens for flooded or miss-forwarded frames. | This test measures the address learning rate of the DUT, in accordance with [[https://tools.ietf.org/html/rfc2889#section-5.8 |section 5.8 of RFC 2889]]. A minimum of 3 DUT ports are required for this test, a learning port where frames first arrive at the DUT, a test port where frames are forwarded and returned to the source, and a monitoring port where the test device listens for flooded or miss-forwarded frames. | ||
Line 45: | Line 47: | ||
=== Scale of Activation === | === Scale of Activation === | ||
- | o Throughput.RFC2889.AddressCachingCapacity | + | o Activation.RFC2889.AddressCachingCapacity |
This test measures the address cache capacity of the DUT, in accordance with [[https://tools.ietf.org/html/rfc2889#section-5.7 |section 5.7 of RFC 2889]]. A minimum of 3 DUT ports are required for this test, a learning port where frames first arrive at the DUT, a test port where frames are forwarded and returned to the source, and a monitoring port where the test device listens for flooded or miss-forwarded frames. | This test measures the address cache capacity of the DUT, in accordance with [[https://tools.ietf.org/html/rfc2889#section-5.7 |section 5.7 of RFC 2889]]. A minimum of 3 DUT ports are required for this test, a learning port where frames first arrive at the DUT, a test port where frames are forwarded and returned to the source, and a monitoring port where the test device listens for flooded or miss-forwarded frames. |