Directory structure and what modules go where
├── 3rd_party # placeholder for all scripts, which license is not compatible with OPNFV licenses ├── ci # CI related scripts, i.e. detailed CI job definition and script for graph generation from results ├── conf # all configuration files including a TC definition │ └── integration # integration TC specific configuration files ├── core # implementation of controllers (to control vswitch, vnf and trafficgen configuration and execution); # implementation of generic classes, which assure selection of components selected by configuration; # definition of constants used for results processing and reporting ├── docs # documentation files in RST format; See OPNFVDOCS project for more details about documentation # structure, description of local and automatic DOC generation, etc. ├── jobs # not used by VSPERF ├── src # external tools required by vsperf are cloned and compiled here; Directory structure contains a set # of makefiles, definition of tools' repositories and versions and in case of DPDK and OVS it contains # an implementation of basic functions to control DPDK and OVS. These files should be probably moved # into vswitch directory. ├── systems # installation scripts for various Linux distributions ├── testcases # implementation of testcases execution logic ├── tools # includes a set of functions for interaction with OS; Classes used for configuration and control of # external tools are stored in subdirectories (except VNF & vSwitch) │ ├── collectors # wrapper classes for collectors, which monitors and record system utilization during TC execution │ ├── llc_management # wrapper classes for LCC configuration │ ├── load_gen # wrapper classes for generators of background load │ ├── opnfvdashboard # class used for export of VSPERF CI results into OPNFV result database │ ├── pkt_fwd # class configures testpmd as a packet forwarder for P2P deployment; It should be generalized # to support standard deployments and moved to vswitches directory │ ├── pkt_gen # wrapper classes for traffic generators │ └── report # templates and functions used for report generation for performance testcases ├── vnfs # classes for VNF deployment and control (currently only QEMU is supported) ├── vswitches # classes for vSwitch configuration and control (OVS with DPDK, Vanilla OVS and VPP are supported) └── yardstick # example testcases for yardstick to demonstrate yardstick and vsperf possible integration; # see vsperf documentation for further details |
I believe that this topic can be covered by self study by interested vsperf users based on the information provided above.
Explain the core modules (core folder)
core ├── component_factory.py # class used for creation of objects, which will control tools used during TC execution; # Component factory is called from testcase.py to create instances of vSwitch, trafficgen # VNFs, etc. It is also called directly from vsperf script in case of "--mode trafficgen". ├── loader │ ├── loader.py # Support classes which import and provide information about all implemented vsperf │ └── loader_servant.py # classes for vSwitch, traffcigen, VNF. loadgen, collector and packet generator. # Loader and LoaderServant classes are used by testcase.py and vsperf to obtain # data for proper component factory invocation. ├── pktfwd_controller.py # Controller which implements P2P scenario with DPDK testpmd as a packet forwarder. ├── results │ ├── results_constants.py # definition of constants used for results processing and reporting │ └── results.py # IResults interface used by traffic controllers to hold results from traffic generators ├── traffic_controller.py # Generic implementation of traffic generator controller. ├── traffic_controller_rfc2544.py # RFC2544 specific specialization of traffic controller, which according to VSPERF/TC # configuration executes RFC2544 Throughput, Back2Back, Continuous stream # or Burst traffic. Required traffic type must be supported by selected trafficgen. ├── traffic_controller_rfc2889.py # RFC2889 specific specialization of traffic controller, which according to VSPERF/TC # configuration executes RFC2899 Caching, Forwarding or Learning tests. This is currently # supported only by Spirent TestCenter traffic generator. ├── vnf_controller.py # Implementation of VNF controller, which based on TC configuration (e.g. selected # deployment or TestSteps) creates, starts and stops all VNFs required for TC execution. ├── vswitch_controller_p2p.py # vSwitch controller which configures vSwitch (currently only OVS is supported) according # to P2P deployment scenario - see vsperf doc for additional details about deployments. ├── vswitch_controller_pxp.py # vSwitch controller which configures vSwitch (currently only OVS is supported) according # to PXP (PVP, PVVP, PVPV, etc.) deployment scenario - see vsperf doc for additional # details about deployments. ├── vswitch_controller_clean.py # Simple vSwitch controller, which just ensures, that vswitch and all required processes # (e.g. ovsdb) are properly executed. This controller is used by step driven testcase # with "clean" deployment, where vSwitch configuration is driven by TestSteps. ├── vswitch_controller_op2p.py # vSwitch controller used for tunneling protocols, where vswitch is configured to either # encapsulate or decapsulate the incoming traffic from the trafficgen to/from selected # tunneling protocol (i.e. GRE,VxLAN or Geneve). This is used by "op2p" deployment and # it configures unidirectional traffic for OVS. Trafficgen must support given tunneling # protocol. Currently only IxNet is supported. ├── vswitch_controller_ptunp.py # vSwitch controller used for testing of tunneling protocols, where both encapsulation # and decapsulation of selected tunneling protocol is performed by vSwitch. Currently # only OVS is supported. However any supported trafficgen can be used. └── vswitch_controller.py # Implementation of generic IVswitchController interface used by specific vswitch # controller implementations. |
I believe that this topic can be covered by self study by interested vsperf users based on the information provided above.