doc: use corelist instead of coremask

[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 e440268..e505fb3 100644 (file)
--- a/doc/guides/sample_app_ug/exception_path.rst
+++ b/doc/guides/sample_app_ug/exception_path.rst
@@ -31,10 +31,10 @@
 Exception Path Sample Application
 =================================
 
-The Exception Path sample application is a simple example that demonstrates the use of the Intel® DPDK
+The Exception Path sample application is a simple example that demonstrates the use of the DPDK
 to set up an exception path for packets to go through the Linux* kernel.
 This is done by using virtual TAP network interfaces.
-These can be read from and written to by the Intel® DPDK application and
+These can be read from and written to by the DPDK application and
 appear to the kernel as a standard network interface.
 
 Overview
@@ -46,13 +46,12 @@ The second thread reads from a TAP interface and writes the data unmodified to t
 
 The packet flow through the exception path application is as shown in the following figure.
 
-.. _figure_1:
+.. _figure_exception_path_example:
 
-**Figure 1. Packet Flow**
+.. figure:: img/exception_path_example.*
 
-.. image2_png has been replaced
+   Packet Flow
 
-|exception_path_example|
 
 To make throughput measurements, kernel bridges must be setup to forward data between the bridges appropriately.
 
@@ -74,7 +73,7 @@ Compiling the Application
         export RTE_TARGET=x86_64-native-linuxapp-gcc
 
 This application is intended as a linuxapp only.
-See the *Intel® DPDK Getting Started Guide* for possible RTE_TARGET values.
+See the *DPDK Getting Started Guide* for possible RTE_TARGET values.
 
 #.  Build the application:
 
@@ -99,11 +98,11 @@ where:
 
 *   -o OUT_CORES: A hex bitmask of cores which write to NIC
 
-Refer to the *Intel® DPDK Getting Started Guide* for general information on running applications
+Refer to the *DPDK Getting Started Guide* for general information on running applications
 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,
@@ -113,7 +112,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
 ~~~~~~~~~~~~~~~~~~
@@ -135,8 +134,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:
@@ -174,7 +172,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;
     }
@@ -222,7 +220,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.
 
@@ -327,4 +325,3 @@ To remove bridges and persistent TAP interfaces, the following commands are used
     brctl delbr br0
     openvpn --rmtun --dev tap_dpdk_00
 
-.. |exception_path_example| image:: img/exception_path_example.svg