ethdev: remove name from extended statistic fetch
[dpdk.git] / doc / guides / faq / faq.rst
index 0686e17..3228b92 100644 (file)
@@ -88,9 +88,7 @@ the wrong socket, the application simply will not start.
 On application startup, there is a lot of EAL information printed. Is there any way to reduce this?
 ---------------------------------------------------------------------------------------------------
 
-Yes, each EAL has a configuration file that is located in the /config directory. Within each configuration file, you will find CONFIG_RTE_LOG_LEVEL=8.
-You can change this to a lower value, such as 6 to reduce this printout of debug information. The following is a list of LOG levels that can be found in the rte_log.h file.
-You must remove, then rebuild, the EAL directory for the change to become effective as the configuration file creates the rte_config.h file in the EAL directory.
+Yes, the option ``--log-level=`` accepts one of these numbers:
 
 .. code-block:: c
 
@@ -103,6 +101,9 @@ You must remove, then rebuild, the EAL directory for the change to become effect
     #define RTE_LOG_INFO 7U     /* Informational. */
     #define RTE_LOG_DEBUG 8U    /* Debug-level messages. */
 
+It is also possible to change the maximum (and default level) at compile time
+with ``CONFIG_RTE_LOG_LEVEL``.
+
 
 How can I tune my network application to achieve lower latency?
 ---------------------------------------------------------------
@@ -157,32 +158,13 @@ I am getting errors about not being able to open files. Why?
 
 As the DPDK operates, it opens a lot of files, which can result in reaching the open files limits, which is set using the ulimit command or in the limits.conf file.
 This is especially true when using a large number (>512) of 2 MB huge pages. Please increase the open file limit if your application is not able to open files.
-This can be done either by issuing a ulimit command or editing the limits.conf file. Please consult Linux* manpages for usage information.
-
-
-Does my kernel require patching to run the DPDK?
-------------------------------------------------
-
-Any kernel greater than version 2.6.33 can be used without any patches applied. The following kernels may require patches to provide hugepage support:
-
-*   Kernel version 2.6.32 requires the following patches applied:
-
-    *   `mm: hugetlb: add hugepage support to pagemap <http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5dc37642cbce34619e4588a9f0bdad1d2f870956>`_
-
-    *   `mm: hugetlb: fix hugepage memory leak in walk_page_range() <http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d33b9f45bd24a6391bc05e2b5a13c1b5787ca9c2>`_
-
-    *   `hugetlb: add nodemask arg to huge page alloc, free and surplus adjust functions <http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6ae11b278bca1cd41651bae49a8c69de2f6a6262>`_
-        (not mandatory, but recommended on a NUMA system to support per-NUMA node hugepages allocation)
-
-*   Kernel version 2.6.31, requires the above patches plus the following:
-
-    *   `UIO: Add name attributes for mappings and port regions <http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8205779114e8f612549d191f8e151526a74ab9f2>`_
+This can be done either by issuing a ulimit command or editing the limits.conf file. Please consult Linux manpages for usage information.
 
 
 VF driver for IXGBE devices cannot be initialized
 -------------------------------------------------
 
-Some versions of Linux* IXGBE driver do not assign a random MAC address to VF devices at initialization.
+Some versions of Linux IXGBE driver do not assign a random MAC address to VF devices at initialization.
 In this case, this has to be done manually on the VM host, using the following command:
 
 .. code-block:: console
@@ -214,10 +196,10 @@ When trying to send packets from an application to itself, meaning smac==dmac, u
 Check on register ``LLE(PFVMTXSSW[n])``, which allows an individual pool to send traffic and have it looped back to itself.
 
 
-Can I split packet RX to use DPDK and have an application's higher order functions continue using Linux* pthread?
------------------------------------------------------------------------------------------------------------------
+Can I split packet RX to use DPDK and have an application's higher order functions continue using Linux pthread?
+----------------------------------------------------------------------------------------------------------------
 
-The DPDK's lcore threads are Linux* pthreads bound onto specific cores. Configure the DPDK to do work on the same
+The DPDK's lcore threads are Linux pthreads bound onto specific cores. Configure the DPDK to do work on the same
 cores and run the application's other work on other cores using the DPDK's "coremask" setting to specify which
 cores it should launch itself on.