vmxnet3: support port hotplug

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

diff --git a/doc/guides/sample_app_ug/load_balancer.rst b/doc/guides/sample_app_ug/load_balancer.rst
index 8ec47ae..615826a 100644 (file)
--- a/doc/guides/sample_app_ug/load_balancer.rst
+++ b/doc/guides/sample_app_ug/load_balancer.rst
@@ -44,13 +44,12 @@ Overview
 
 The architecture of the Load Balance application is presented in the following figure.
 
-.. _figure_5:
+.. _figure_load_bal_app_arch:
 
-**Figure 5. Load Balancer Application Architecture**
+.. figure:: img/load_bal_app_arch.*
 
-.. image8_png has been renamed
+   Load Balancer Application Architecture
 
-|load_bal_app_arch|
 
 For the sake of simplicity, the diagram illustrates a specific case of two I/O RX and two I/O TX lcores off loading the packet I/O
 overhead incurred by four NIC ports from four worker cores, with each I/O lcore handling RX/TX for two NIC ports.
@@ -220,7 +219,7 @@ The application has built-in performance enhancements for the NUMA case:
 #.  Memory for the NIC RX or TX rings is allocated on the same socket with the lcore handling the respective ring.
 
 In the case where multiple CPU sockets are used in the system,
-it is recommended to enable at least one lcore to fulfil the I/O role for the NIC ports that
+it is recommended to enable at least one lcore to fulfill the I/O role for the NIC ports that
 are directly attached to that CPU socket through the PCI Express* bus.
 It is always recommended to handle the packet I/O with lcores from the same CPU socket as the NICs.
 
@@ -241,5 +240,3 @@ are on the same or different CPU sockets, the following run-time scenarios are p
 #.  ABC: The packet is received on socket A, it is processed by an lcore on socket B,
     then it has to be transmitted out by a NIC connected to socket C.
     The performance price for crossing the CPU socket boundary is paid twice for this packet.
-
-.. |load_bal_app_arch| image:: img/load_bal_app_arch.png