doc: add generic build instructions for sample apps

[dpdk.git] / doc / guides / sample_app_ug / exception_path.rst

diff --git a/doc/guides/sample_app_ug/exception_path.rst b/doc/guides/sample_app_ug/exception_path.rst
index 3cc7cbe..d7f45e6 100644 (file)
--- a/doc/guides/sample_app_ug/exception_path.rst
+++ b/doc/guides/sample_app_ug/exception_path.rst
@@ -58,28 +58,9 @@ To make throughput measurements, kernel bridges must be setup to forward data be
 Compiling the Application
 -------------------------
 
-#.  Go to example directory:
+To compile the sample application see :doc:`compiling`.
 
-    .. code-block:: console
-
-        export RTE_SDK=/path/to/rte_sdk
-        cd ${RTE_SDK}/examples/exception_path
-
-#.  Set the target (a default target will be used if not specified).
-    For example:
-
-    .. code-block:: console
-
-        export RTE_TARGET=x86_64-native-linuxapp-gcc
-
-This application is intended as a linuxapp only.
-See the *DPDK Getting Started Guide* for possible RTE_TARGET values.
-
-#.  Build the application:
-
-    .. code-block:: console
-
-        make
+The application is located in the ``exception_path`` sub-directory.
 
 Running the Application
 -----------------------
@@ -102,7 +83,7 @@ Refer to the *DPDK Getting Started Guide* for general information on running app
 and the Environment Abstraction Layer (EAL) options.
 
 The number of bits set in each bitmask must be the same.
-The coremask -c parameter of the EAL options should include IN_CORES and OUT_CORES.
+The coremask -c or the corelist -l parameter of the EAL options should include IN_CORES and OUT_CORES.
 The same bit must not be set in IN_CORES and OUT_CORES.
 The affinities between ports and cores are set beginning with the least significant bit of each mask, that is,
 the port represented by the lowest bit in PORTMASK is read from by the core represented by the lowest bit in IN_CORES,
@@ -112,7 +93,7 @@ For example to run the application with two ports and four cores:
 
 .. code-block:: console
 
-    ./build/exception_path -c f -n 4 -- -p 3 -i 3 -o c
+    ./build/exception_path -l 0-3 -n 4 -- -p 3 -i 3 -o c
 
 Getting Statistics
 ~~~~~~~~~~~~~~~~~~
@@ -134,8 +115,7 @@ The following sections provide some explanation of the code.
 Initialization
 ~~~~~~~~~~~~~~
 
-Setup of the mbuf pool, driver and queues is similar to the setup done in the L2 Forwarding sample application
-(see Chapter 9 "L2 forwarding Sample Application (in Real and Virtualized Environments" for details).
+Setup of the mbuf pool, driver and queues is similar to the setup done in the :ref:`l2_fwd_app_real_and_virtual`.
 In addition, the TAP interfaces must also be created.
 A TAP interface is created for each lcore that is being used.
 The code for creating the TAP interface is as follows:
@@ -173,7 +153,7 @@ The code for creating the TAP interface is as follows:
         }
 
         if (name)
-            rte_snprintf(name, IFNAMSIZ, ifr.ifr_name);
+            snprintf(name, IFNAMSIZ, ifr.ifr_name);
 
         return fd;
     }
@@ -221,7 +201,7 @@ This function first checks the lcore_id against the user provided input_cores_ma
 if this core is reading from or writing to a TAP interface.
 
 For the case that reads from a NIC port, the packet reception is the same as in the L2 Forwarding sample application
-(see Section 9.4.6, "Receive, Process and Transmit Packets").
+(see :ref:`l2_fwd_app_rx_tx_packets`).
 The packet transmission is done by calling write() with the file descriptor of the appropriate TAP interface
 and then explicitly freeing the mbuf back to the pool.