Rtnl2ExtractFromPhysicalRxQueue

Rtnl2ExtractFromPhysicalRxQueue checks the DMA ring of the specified Physical Receive Queue, and extracts buffers from the FIFO of filled buffers.

Syntax

Copy

BOOL Rtnl2ExtractFromPhysicalRxQueue(
  [in]                RTNL2_HPHYSICAL_RX_QUEUE PhysicalRxQueue, 
  [in]                ULONG NbMaxToExtract, 
  [out]               RTNL2_BUFFER_HEADER **pExtracted, 
  [out, optional]     ULONG *NbExtracted
);

Parameters

[in] PhysicalRxQueue

A handle to the Physical Receive Queue obtained from Rtnl2AcquirePhysicalRxQueue.

[in] NbMaxToExtract

The maximum number of buffers to extract from the FIFO of filled buffers. Use zero if you don’t want to extract any buffer but just query whether the queue is empty. Use ULONG_MAX if you want to extract all filled buffers.

[out] pExtracted

The address of the first buffer header extracted from the FIFO of filled buffers.

[out, optional] NbExtracted

The number of buffers in the returned pExtracted list.

Return Value

If the function succeeds, it returns TRUE. If the function fails, it returns FALSE. Call GetLastError to obtain an error code.

Possible error codes:

Error code	Meaning
ERROR_NOT_READY	The calling process has not called Rtnl2Init.
ERROR_INVALID_PARAMETER	One of these conditions occurred: The supplied Physical Receive Queue handle is invalid. pExtracted is NULL.
RTNL2_ERROR_PHYSICAL_RX_QUEUE_IS_RELEASING	Another thread of the calling process is executing Rtnl2ReleasePhysicalRxQueue at the same time.
RTNL2_ERROR_PHYSICAL_RX_QUEUE_CONCURRENT_ACCESS_NOT_ALLOWED	The Physical Transmit Queue has been acquired with the RTNL2_PHYSICAL_RX_QUEUE_FLAG_NO_SERIALIZE flag and another thread of the calling process is executing Rtnl2SubmitToPhysicalRxQueue at the same time.
RTNL2_ERROR_NO_MORE_COMMUNICATION	Unable to communicate with the NL2 process. This might be because the NL2 process is not running anymore, or because an application process thread was terminated during a previous call to an NL2 API function.

Characteristics

Real-time
Deterministic	Yes if the Physical Receive Queue was acquired with the RTNL2_PHYSICAL_RX_QUEUE_FLAG_NO_SERIALIZE flag and the underlying driver supports deterministic receive operation, No otherwise. Please refer to your driver’s documentation to determine whether it supports deterministic receive operation.
Local memory usage
Process	External MSpace usage	Internal MSpace usage
System	No	No
NL2 process	No	No
Calling process	No	No
Contiguous memory usage
Usage	No

Requirements

Minimum supported version	Header	Library
eRTOS 1.0 SDK	Rtnl2Api.h	Rtnl2Api.lib