[BUG] Zynq port: dmaRX_TX_BUFFER_SIZE is too big

[mike919192]

Describe the bug
I noticed that there is a new issue in the Zynq port with the newest release 4.3.2. There was an additional check added to pxGetNetworkBufferWithDescriptor here:

FreeRTOS-Plus-TCP/source/portable/BufferManagement/BufferAllocation_1.c

Line 241 in 28dd66c

( xRequestedSizeBytes <= ( ipconfigNETWORK_MTU + ipSIZE_OF_ETH_HEADER ) ) )

So the function does not succeed if the requested bytes is greater than ipconfigNETWORK_MTU + ipSIZE_OF_ETH_HEADER (normally 1500 + 14)

The Zynq port calls the function using dmaRX_TX_BUFFER_SIZE which is defined to 1536, so the function fails.

FreeRTOS-Plus-TCP/source/portable/NetworkInterface/Zynq/x_emacpsif_dma.c

Line 525 in 28dd66c

pxNewBuffer = pxGetNetworkBufferWithDescriptor( dmaRX_TX_BUFFER_SIZE, ( TickType_t ) 0 );

I'm not familiar enough with it, but is the solution to reduce the value of dmaRX_TX_BUFFER_SIZE?

Target

• IDE and version: Xilinx Vitis 2024.2

Host

• Host OS: Windows 10

[ActoryOu]

Hi @mike919192,
Thank you for bringing this into our attention!
I'll look into it and get back in short.

Thank you.

[tony-josi-aws]

@mike919192

We have created a patch PR here: #1263
Can you try if the fix works for you?

[mike919192]

@tony-josi-aws

Thanks for the quick patch, but it is still failing at the same check.

https://github.com/tony-josi-aws/FreeRTOS-Plus-TCP/blob/119cbb21e7bf7d130c69f0c0d967dacd036d1357/source/portable/BufferManagement/BufferAllocation_1.c#L246

The value of uxMaxNetworkInterfaceAllocatedSizeBytes is now 1526, but the Zynq port is still requesting 1536.

It looks like uxMaxNetworkInterfaceAllocatedSizeBytes is set to niBUFFER_1_PACKET_SIZE - ipBUFFER_PADDING which is 1536 - 12 + 2. Also I don't think it would fix the problem, but it looks like the macros might not be evaluated in the correct order of operations? It looks like the intended math might be 1536 - (12 + 2), but it is executing as 1536 - 12 + 2.

[ActoryOu]

Hi @mike919192,
Thanks for your quick response. For the macro part, I'd like to know how do you get that result.
From the definition of FreeRTOS_IP.h, it defines:

#if ( ipconfigBUFFER_PADDING != 0 )
    #define ipBUFFER_PADDING    ipconfigBUFFER_PADDING
#elif ( UINTPTR_MAX > 0xFFFFFFFFU )
    #define ipBUFFER_PADDING    ( 12U + ipconfigPACKET_FILLER_SIZE )
#else
    #define ipBUFFER_PADDING    ( 8U + ipconfigPACKET_FILLER_SIZE )
#endif

ipBUFFER_PADDING is actually defined with curved bracket if ipconfigBUFFER_PADDING is not defined.
Do you define ipconfigBUFFER_PADDING in your FreeRTOSIPConfig.h? Could you help check if that's defined there?

Thank you.

[mike919192]

Sorry, one thing I wrote was not correct. ipBUFFER_PADDING is actually 8 + 2. I guess my IDE clangd was evaluating it wrong so I checked it using a debugger. I do not have ipconfigBUFFER_PADDING defined, so it is getting the default definition of 0.

So the uxMaxNetworkInterfaceAllocatedSizeBytes value is actually being computed as 1536 - (8 + 2) and the order of operations is correct.

What I wrote about the function failing was still correct though. The xRequestedSizeBytes is 1536 and the uxMaxNetworkInterfaceAllocatedSizeBytes is 1526.

[tony-josi-aws]

@mike919192

Can you try defining the dmaRX_TX_BUFFER_SIZE to (1536 - ipBUFFER_PADDING) and see if that helps?

#define dmaRX_TX_BUFFER_SIZE    (1536 -  ipBUFFER_PADDING)

EDIT: Changed ipconfigBUFFER_PADDING to ipBUFFER_PADDING

[mike919192]

Yes thanks that change allows the function to work, and communication is working again. I'm not very familiar with that code so I didn't know if that was the correct solution or not.

[tony-josi-aws]

Thank you for verifying. We will update and test the patch and then release a newer version.

[mike919192]

@tony-josi-aws Great. In the future if you want, feel free to contact me when you are preparing a release to do a quick test on the Zynq port. It doesn't take too much time for me to check that a new version works in our application.

[tony-josi-aws]

Sure, that would be a great contribution.

[tony-josi-aws]

@mike919192 We have released a new version, V4.3.3 patching the reported issue.

[mike919192]

Thanks for the quick resolution.