Raw Rx back pressure triggers excessive amount of logs

[AlexImagineComm]

Please find below the description of the test:

1. Raw Tx using EFA sends uncompressed video stream (frame rate 30000/1001)
2. Raw Rx has a back-pressure, it means it can not receive the stream temporary and as such "stuck" in the payloadReceivedCallback, then it tries to push the data out.
3. At this point the Tx is not aware about this situation and keeps pushing video. Tx never got informed of the back-pressure on the Rx.
4. The Rx drops packages and starts to log the following log message: ERROR Failed to get Rx Payload State entry from pool.
5. These messages are printed twice every ms, i.e. thousands of them every second.
6. Then back-pressure is relived - the Rx works as expected and just "forgets" about all these dropped packages.

Can the CDI somehow filter these "Failed to get Rx Payload State entry from pool." and not log these in such a huge amount ?
May be create more descriptive message and not to log all these ? May be let the Rx know about the back-pressure condition ?
What is the expected behavior of the Rx during the back-pressure period ? Is it right that all the packages are just lost and the Tx even does not get informed about it ?
Regards
Alex

[mhhen]

Alex,

Thank you for bringing this issue to our attention. We will be adding logic to suppress these type of repetitive error messages and provide a resource allocation error to the application using the existing user-registered callback function (CdiRawRxCallback or CdiAvmRxCallback). We will update this issue when the code is publically available.

Since the SDK was designed for streaming data in real-time applications, it does not communicate back-pressure (ie. from receiver to a transmitter). If downstream applications generate back-pressure, there is going to be a backup somewhere and payloads will need to be discarded. An application could detect back-pressure conditions and use out-of-band communication to notify upstream components to reduce the frequency and/or size of payloads. The changes noted above will provide the application with a mechanism it can use to determine if back pressure is occurring.

[AlexImagineComm]

Than you very much for your reply.
We are looking forward to get the implementation you wrote above:

provide a resource allocation error to the application using the existing user-registered callback function (CdiRawRxCallback or CdiAvmRxCallback).

The question here is why the error would be added to the Rx callback functions only ? According to my understanding this error should be provided to the Tx callback as well (CdiRawTxCallback & CdiAvmTxCallback). They both receive CdiRawTxCbData ( or CdiAvmTxCbData), which contains CdiCoreCbData.
Here's the description of this data:

typedef struct {
    /// @brief Core common data <b>shared</b> between registered user <b>TX/RX</b> callback functions.
    CdiCoreCbData core_cb_data;

This means that this core_cb_data should share status of the payload between the Tx and the Rx. In this case the Rx is in trouble (back pressure) and dropping packages and I think the Rx should inform the Tx that the packages being dropped by CDI.

Regards
Alex

[mhhen]

Alex,

The error would be only added to the Rx callback function, since there is currently no method to communicate back-pressure from the receiver to the transmitter. The socket-based probe interface could be extended to provide this mechanism, but it was designed to manage connections not network packets. If this condition occurs in a real-time application, it seems that out-of-band mechanisms would need to be implemented that might require signification changes to the workflow in order to eliminate the problem (ie. reduce frame-rate or frame size). This could require changes to components that don't support CDI.

[yanniel]

Mike, Alex.

Please consider my thoughts below:

"If this condition occurs in a real-time application, it seems that out-of-band mechanisms would need to be implemented". This is reasonable when the Raw interface of the CDI SDK is used.

However, interoperability is an important driver behind the use of the AVM interface. The implementation of an out of band mechanism would be vendor specific (at best a few vendors could band together to agree on a common mechanism). The lack of standardization of this out-of-band mechanism when the AVM interface is used is contradictory to the goal of achieving interoperability.