Add configuration option to prevent configASSERT checks on ipBUFFER_PADDING#1271
Merged
tony-josi-aws merged 3 commits intoJun 26, 2025
Merged
Conversation
… checks on ipBUFFER_PADDING in FreeRTOS_IP_Utils.c/vPreCheckConfigs( void ) * Defaults to ipconfigDISABLE to build with configASSERT checks in place. * User settable to ipconfigENABLE to eliminate configASSERT checks.
Member
|
@blanco-ether |
Contributor
|
I think it would be useful to include alignment settings in the macro. on Platforms with a cache, other values are possible, depending on the size of the cache lines. |
Member
|
@devprodest |
aggarg
approved these changes
Jun 25, 2025
moninom1
approved these changes
Jun 25, 2025
Contributor
Author
|
If I understand what you're asking, no.
Some more detail to help make things clearer...
A user who ports to a MAC that does not have a feature to padd the start of
a received packet (2 bytes) will likely need to
set ipconfigPACKET_FILLER_SIZE to 0
in their FreeRTOSIPConfig.h. Maybe more specifically, when a user
implements zero copy buffers on a port to a MAC that does not support any
way to automatically
add padding. It may be that when porting to a MAC that lacks the padding
feature but not implementing zero copy buffers they will not need to change
ipconfigPACKET_FILLER_SIZE in their FreeRTOSIPConfig.h.
In our case, I ported FreeRTOS-Plus-TCP to the MAC in the processor in our
device (Actel/Microsemi, now Microchip: A2F200) years ago and implemented
zero copy
buffers right off to save memory. I needed to set
ipconfigPACKET_FILLER_SIZE to 0 to make it work. I recently needed to
update to a newer version of FreeRTOS-Plus-TCP
to take advantage of a bug fix related to an orphaned socket that was
closed before being accepted caused FreeRTOS_accept to return a pointer to
freed memory.
The port to the new version required minor changes and works fine except
fails asserts because of the need to set ipconfigPACKET_FILLER_SIZE to 0.
The configASSERTs will fail when ipconfigPACKET_FILLER_SIZE is set to less
than 2.
Hope that helps.
Thanks
…On Wed, Jun 25, 2025 at 5:33 AM Tony Josi ***@***.***> wrote:
*tony-josi-aws* left a comment (FreeRTOS/FreeRTOS-Plus-TCP#1271)
<#1271 (comment)>
@devprodest <https://github.com/devprodest>
Do you mean having platform-specific alignment macros for different
supported architectures?
—
Reply to this email directly, view it on GitHub
<#1271 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEC37YIFSHIXFQXLVIU3NQL3FJUHJAVCNFSM6AAAAAB76FNEKOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMBUGA4TEMZWG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Contributor
Author
|
My apologies,
I thought that
Do you mean having platform-specific alignment macros for different
supported architectures?
was a question for me.
Nevermind.
…On Wed, Jun 25, 2025 at 5:33 AM Tony Josi ***@***.***> wrote:
*tony-josi-aws* left a comment (FreeRTOS/FreeRTOS-Plus-TCP#1271)
<#1271 (comment)>
@devprodest <https://github.com/devprodest>
Do you mean having platform-specific alignment macros for different
supported architectures?
—
Reply to this email directly, view it on GitHub
<#1271 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEC37YIFSHIXFQXLVIU3NQL3FJUHJAVCNFSM6AAAAAB76FNEKOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMBUGA4TEMZWG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
ActoryOu
approved these changes
Jun 26, 2025
Contributor
Yes, unfortunately it is. |
Member
|
@devprodest |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Added ipconfigSUPPRESS_BUFFER_PADDING_CHECK to prevent configASSERT checks on ipBUFFER_PADDING in FreeRTOS_IP_Utils.c/vPreCheckConfigs( void )
Test Steps
Observe that when source built while ipconfigSUPPRESS_BUFFER_PADDING_CHECK either not defined in user configuration or defined as ipconfigDISABLE, the configASSERTs to validate optimal settings for ipBUFFER_PADDING are also built as in existing code base. The configASSERTS are not built when the default setting is overridden in a user configuration by defining ipconfigSUPPRESS_BUFFER_PADDING_CHECK as ipconfigENABLE.
Checklist:
Related Issue
Setting ipconfigPACKET_FILLER_SIZE to 0 is necessary when porting to a MAC controller that does not have an option to pad the start of a received packet within a word boundary to optimize access to IP fields. Setting ipconfigPACKET_FILLER_SIZE to 0 causes configASSERT checks related to validating ipBUFFER_PADDING to fail.
Forum discussion: https://forums.freertos.org/t/assert-fail-using-zero-copy-buffers-porting-freertos-plus-tcp-v3-1-0-to-v4-2-2/23254
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.