diff options
Diffstat (limited to 'doc/guides/prog_guide/multi_proc_support.rst')
| -rw-r--r-- | doc/guides/prog_guide/multi_proc_support.rst | 22 |
1 files changed, 17 insertions, 5 deletions
diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst index 1384fe33..a84083b9 100644 --- a/doc/guides/prog_guide/multi_proc_support.rst +++ b/doc/guides/prog_guide/multi_proc_support.rst @@ -176,7 +176,7 @@ Some of these are documented below: * The use of function pointers between multiple processes running based of different compiled binaries is not supported, since the location of a given function in one process may be different to its location in a second. - This prevents the librte_hash library from behaving properly as in a multi-threaded instance, + This prevents the librte_hash library from behaving properly as in a multi-process instance, since it uses a pointer to the hash function internally. To work around this issue, it is recommended that multi-process applications perform the hash calculations by directly calling @@ -263,9 +263,9 @@ To send a request, a message descriptor ``rte_mp_msg`` must be populated. Additionally, a ``timespec`` value must be specified as a timeout, after which IPC will stop waiting and return. -For synchronous synchronous requests, the ``rte_mp_reply`` descriptor must also -be created. This is where the responses will be stored. The list of fields that -will be populated by IPC are as follows: +For synchronous requests, the ``rte_mp_reply`` descriptor must also be created. +This is where the responses will be stored. +The list of fields that will be populated by IPC are as follows: * ``nb_sent`` - number indicating how many requests were sent (i.e. how many peer processes were active at the time of the request). @@ -273,7 +273,7 @@ will be populated by IPC are as follows: those peer processes that were active at the time of request, how many have replied) * ``msgs`` - pointer to where all of the responses are stored. The order in - which responses appear is undefined. Whendoing sycnrhonous requests, this + which responses appear is undefined. When doing synchronous requests, this memory must be freed by the requestor after request completes! For asynchronous requests, a function pointer to the callback function must be @@ -309,6 +309,13 @@ If a response is required, a new ``rte_mp_msg`` message descriptor must be constructed and sent via ``rte_mp_reply()`` function, along with ``peer`` pointer. The resulting response will then be delivered to the correct requestor. +.. warning:: + Simply returning a value when processing a request callback will not send a + response to the request - it must always be explicitly sent even in case + of errors. Implementation of error signalling rests with the application, + there is no built-in way to indicate success or error for a request. Failing + to do so will cause the requestor to time out while waiting on a response. + Misc considerations ~~~~~~~~~~~~~~~~~~~~~~~~ @@ -318,6 +325,11 @@ supported. However, since sending messages (not requests) does not involve an IPC thread, sending messages while processing another message or request is supported. +Since the memory sybsystem uses IPC internally, memory allocations and IPC must +not be mixed: it is not safe to use IPC inside a memory-related callback, nor is +it safe to allocate/free memory inside IPC callbacks. Attempting to do so may +lead to a deadlock. + Asynchronous request callbacks may be triggered either from IPC thread or from interrupt thread, depending on whether the request has timed out. It is therefore suggested to avoid waiting for interrupt-based events (such as alarms) |