Differences

This shows you the differences between two versions of the page.

--- wiki:vsperf [2015/09/08 15:56]
Billy O'Mahony [IVSwitch]
+++ wiki:vsperf [2015/09/22 12:49] (current)
Billy O'Mahony [Typical Test Sequence]
@@ Line 24: / Line 24: @@
 {{:vsperf:vsperf.msc.png?900|}}
-//This diagram was generated using [[http://www.mcternan.me.uk/mscgen/|mscgen]]. For ease of editing the text used to generate the diagram is included below.//
+//This diagram was generated using [[http://www.mcternan.me.uk/mscgen/|mscgen]].//
-======= Test Configuration ======
-Details of ''conf/01_testcase.conf'' goes here.
 ====== Configuration =======
@@ Line 82: / Line 78: @@
+**IVnf**
+<code>
+    start(memory, cpus,
+          monitor_path, shared_path_host,
+          shared_path_guest, guest_prompt)
+    stop()
+    execute(command)
+    wait(guest_prompt)
+    execute_and_wait (command)
+</code>
+**ITrafficGenerator**
+<code>
+    connect()
+    disconnect()
+    send_burst_traffic(traffic, numpkts, time, framerate)
+    send_cont_traffic(traffic, time, framerate)
+    start_cont_traffic(traffic, time, framerate)
+    stop_cont_traffic(self):
+    send_rfc2544_throughput(traffic, trials, duration, lossrate)
+    start_rfc2544_throughput(traffic, trials, duration, lossrate)
+    wait_rfc2544_throughput(self)
+    send_rfc2544_back2back(traffic, trials, duration, lossrate)
+    start_rfc2544_back2back(traffic, , trials, duration, lossrate)
+    wait_rfc2544_back2back()
+</code>
+Note send_xxx() blocks whereas start_xxx does not and must be followed by a subsequent call to wait_xxx().
-=====IVnf=====
-=====ITrafficGenerator=====
 ====== Controllers ======
-====== Component Loader ======
+Controllers are used in conjunction with abstract interfaces as way of decoupling the control of vSwtiches, VNFs and TrafficGenerators from other components.
-====== Component Factory ======
+The controlled classes provide basic primitive operations. The Controllers sequence and co-ordinate these primitive operation in to useful actions. For instance the vswitch_controller_PVP can be used to bring any vSwitch (that implements the primitives defined in IVSwitch) into the configuration required by the Phy-to-Phy  Deployment Scenario.
+In order to support a new vSwitch only a new implementation of IVSwitch needs be created for the new vSwitch to be capable of fulfilling all the Deployment Scenarios provided for by existing or future vSwitch Controllers.
+Similarly if a new Deployment Scenario is required it only needs to be written once as a new vSwitch Controller and it will immediately be capable of controlling all existing and future vSwitches in to that Deployment Scenario.
+Similarly the Traffic Controllers can be used to co-ordinate basic operations provided by implementers of ITrafficGenerator to provide useful tests. Though traffic generators generally already implement full test cases i.e. they both generate suitable traffic and analyse returned traffic in order to implement a test which has typically been predefined in an RFC document. However the Traffic Controller class allows for the possibility of further enhancement - such as iterating over tests for various packet sizes or creating new tests.
+**Traffic Controller's Role**
+{{:vsperf:traffic_controller.png?900|}}
+====== Loader & Component Factory ======
+The working of the Loader package (which is responsible for //finding// arbitrary classes based on configuration data) and the Component Factory which is responsible for //choosing// the correct class for a particular situation - e.g. Deployment Scenario can be seen in this diagram.
+{{:vsperf:factory_and_loader.png?900|}}
+====== Routing Tables ======
+Vsperf uses a standard set of routing tables in order to allow tests to easily mix and match Deployment Scenarios (PVP, P2P topology), Tuple Matching and Frame Modification requirements.
+<code>
+                    +--------------+
+                    |              |
+                    | Table 0      |  table#0 - Match table. Flows designed to force 5 & 10 tuple matches go here.
+                    |              |
+                    +--------------+
+                          |
+                          |
+                          v
+                    +--------------+  table#1 - Routing table. Flows to route packets between ports goes here.
+                    |              |  The chosen port is communicated to subsequent tables by setting the
+                    | Table 1      |  metadata value to the egress port number. Generally this table
+                    |              |  is set-up by by the vSwitchController.
+                    +--------------+
+                          |
+                          |
+                          v
+                    +--------------+  table#2 - Frame modification table. Frame modification flow rules are
+                    |              |  isolated in this table so that they can be turned on or off
+                    | Table 2      |  without affecting the routing or tuple-matching flow rules.
+                    |              |  This allows the frame modification and tuple matching required by the
+                    +--------------+  tests in the VSWITCH PERFORMANCE FOR TELCO NFV test specification
+                          |           to be independent of the Deployment Scenario set up by the vSwitchController.
+                          |
+                          v
+                    +--------------+
+                    |              |
+                    | Table 3      |  table#3 - Egress table. Egress packets on the ports setup in Table 1.
+                    |              |
+                    +--------------+
+</code>
 ======Appendix======

Wiki

User Tools

Site Tools

Differences

Page Tools