Rtnl2ExtractFromPhysicalTxQueue

Rtnl2ExtractFromPhysicalTxQueue checks the DMA ring of the specified Physical Transmit Queue, and extracts buffers from the FIFO of consumed buffers.

Syntax

Copy

BOOL Rtnl2ExtractFromPhysicalTxQueue(
  [in]                mRTNL2_HPHYSICAL_TX_QUEUE PhysicalTxQueue, 
  [in]                ULONG NbMaxToExtract, 
  [out]               RTNL2_BUFFER_HEADER **pExtracted, 
  [out, optional]     ULONG *NbExtracted
);

Parameters

[in] PhysicalTxQueue

A handle to the Physical Transmit Queue obtained from Rtnl2AcquirePhysicalTxQueue.

[in] NbMaxToExtract

The maximum number of buffers to extract from the FIFO of consumed 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 consumed buffers.

[out] pExtracted

The address of the first buffer header extracted from the FIFO of consumed 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 the following conditions occurred: The supplied Physical Receive Queue handle is invalid. pExtracted is NULL.
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.
RTNL2_ERROR_PHYSICAL_TX_QUEUE_CONCURRENT_ACCESS_NOT_ALLOWED	The Physical Transmit Queue has been acquired with the RTNL2_PHYSICAL_TX_QUEUE_FLAG_NO_SERIALIZE flag and another thread of the calling process is executing Rtnl2SubmitToPhysicalTxQueue or Rtnl2GetPhysicalTxQueueTimestamp at the same time.
RTNL2_ERROR_PHYSICAL_TX_QUEUE_IS_RELEASING	Another thread of the calling process is executing Rtnl2ReleasePhysicalTxQueue at the same time.
RTNL2_ERROR_PHYSICAL_TX_QUEUE_NOT_READY	The Physical Transmit Queue is not ready.

Characteristics

Real-time
Deterministic	Yes if the Physical Transmit Queue was acquired with the RTNL2_PHYSICAL_TX_QUEUE_FLAG_NO_SERIALIZE flag and the underlying driver supports deterministic transmit operations. No otherwise. Please refer to your driver’s documentation to determine whether it supports deterministic transmit operations.
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