X-Git-Url: http://git.droids-corp.org/?a=blobdiff_plain;f=doc%2Fguides%2Fprog_guide%2Fenv_abstraction_layer.rst;h=10a10a88325d445654fcc340530e3eea52eed9d3;hb=73db5badb042c2ba668cdc096168932c5d5e692d;hp=cd4d66686fd26e82f366d095ad3588aacd2cc26c;hpb=56297061dfad19a045754ec29de30e5be369bf10;p=dpdk.git diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst index cd4d66686f..10a10a8832 100644 --- a/doc/guides/prog_guide/env_abstraction_layer.rst +++ b/doc/guides/prog_guide/env_abstraction_layer.rst @@ -103,7 +103,7 @@ Multi-process Support ~~~~~~~~~~~~~~~~~~~~~ The Linuxapp EAL allows a multi-process as well as a multi-threaded (pthread) deployment model. -See chapter 2.20 +See chapter :ref:`Multi-process Support ` for more details. Memory Mapping Discovery and Memory Reservation @@ -115,7 +115,7 @@ The physical address of the reserved memory for that memory zone is also returne .. note:: - Memory reservations done using the APIs provided by the rte_malloc library are also backed by pages from the hugetlbfs filesystem. + Memory reservations done using the APIs provided by rte_malloc are also backed by pages from the hugetlbfs filesystem. Xen Dom0 support without hugetbls ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -166,8 +166,10 @@ CPU Feature Identification The EAL can query the CPU at runtime (using the rte_cpu_get_feature() function) to determine which CPU features are available. -User Space Interrupt and Alarm Handling -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +User Space Interrupt Event +~~~~~~~~~~~~~~~~~~~~~~~~~~ + ++ User Space Interrupt and Alarm Handling in Host Thread The EAL creates a host thread to poll the UIO device file descriptors to detect the interrupts. Callbacks can be registered or unregistered by the EAL functions for a specific interrupt event @@ -176,9 +178,35 @@ The EAL also allows timed callbacks to be used in the same way as for NIC interr .. note:: - The only interrupts supported by the DPDK Poll-Mode Drivers are those for link status change, + In DPDK PMD, the only interrupts handled by the dedicated host thread are those for link status change, i.e. link up and link down notification. + ++ RX Interrupt Event + +The receive and transmit routines provided by each PMD don't limit themselves to execute in polling thread mode. +To ease the idle polling with tiny throughput, it's useful to pause the polling and wait until the wake-up event happens. +The RX interrupt is the first choice to be such kind of wake-up event, but probably won't be the only one. + +EAL provides the event APIs for this event-driven thread mode. +Taking linuxapp as an example, the implementation relies on epoll. Each thread can monitor an epoll instance +in which all the wake-up events' file descriptors are added. The event file descriptors are created and mapped to +the interrupt vectors according to the UIO/VFIO spec. +From bsdapp's perspective, kqueue is the alternative way, but not implemented yet. + +EAL initializes the mapping between event file descriptors and interrupt vectors, while each device initializes the mapping +between interrupt vectors and queues. In this way, EAL actually is unaware of the interrupt cause on the specific vector. +The eth_dev driver takes responsibility to program the latter mapping. + +.. note:: + + Per queue RX interrupt event is only allowed in VFIO which supports multiple MSI-X vector. In UIO, the RX interrupt + together with other interrupt causes shares the same vector. In this case, when RX interrupt and LSC(link status change) + interrupt are both enabled(intr_conf.lsc == 1 && intr_conf.rxq == 1), only the former is capable. + +The RX interrupt are controlled/enabled/disabled by ethdev APIs - 'rte_eth_dev_rx_intr_*'. They return failure if the PMD +hasn't support them yet. The intr_conf.rxq flag is used to turn on the capability of RX interrupt per device. + Blacklisting ~~~~~~~~~~~~ @@ -294,8 +322,8 @@ Known Issues The rte_mempool uses a per-lcore cache inside the mempool. For non-EAL pthreads, ``rte_lcore_id()`` will not return a valid number. - So for now, when rte_mempool is used with non-EAL pthreads, the put/get operations will bypass the mempool cache and there is a performance penalty because of this bypass. - Support for non-EAL mempool cache is currently being enabled. + So for now, when rte_mempool is used with non-EAL pthreads, the put/get operations will bypass the default mempool cache and there is a performance penalty because of this bypass. + Only user-owned external caches can be used in a non-EAL context in conjunction with ``rte_mempool_generic_put()`` and ``rte_mempool_generic_get()`` that accept an explicit cache parameter. + rte_ring @@ -313,7 +341,7 @@ Known Issues be preempted by another pthread doing a multi-consumer dequeue on the same ring. - Bypassing this constraint it may cause the 2nd pthread to spin until the 1st one is scheduled again. + Bypassing this constraint may cause the 2nd pthread to spin until the 1st one is scheduled again. Moreover, if the 1st pthread is preempted by a context that has an higher priority, it may even cause a dead lock. This does not mean it cannot be used, simply, there is a need to narrow down the situation when it is used by multi-pthread on the same core. @@ -527,7 +555,7 @@ The most important fields in the structure and how they are used are described b Memory Allocation ^^^^^^^^^^^^^^^^^ -On EAL initialisation, all memsegs are setup as part of the malloc heap. +On EAL initialization, all memsegs are setup as part of the malloc heap. This setup involves placing a dummy structure at the end with ``BUSY`` state, which may contain a sentinel value if ``CONFIG_RTE_MALLOC_DEBUG`` is enabled, and a proper :ref:`element header` with ``FREE`` at the start