-
Notifications
You must be signed in to change notification settings - Fork 3k
Memory manager for unified EMAC #5750
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@kjbracey-arm here's the memory manager and K64F/STM driver changes. |
To maybe slightly reduce confusion, this PR should be against |
Changed the base..... since this branch is based on current master it is ahead of the feature-emac. |
* @param mem Memory buffer | ||
* @return Total length in bytes | ||
*/ | ||
virtual uint32_t get_total_len(emac_mem_buf_t *buf); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's have some const-correctness - this should be a const buf pointer, and the method should be const.
Should all the methods be const apart from free and alloc - if they only touch the buffer, they can't be changing the memory manager's overall state right? I suppose anything that modifies a buffer could be changing housekeeping info. So maybe const methods if they take const buf pointers.
* @param mem Memory buffer | ||
* @return The next memory buffer, or NULL if last | ||
*/ | ||
virtual emac_mem_buf_t *next(emac_mem_buf_t *buf); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, const, and same for the others. Should this be get_next
to match the below?
pbuf->len -= offset; | ||
} | ||
|
||
return (emac_mem_buf_t*)pbuf; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you make all the casting here C++ static_cast
? Would help enforce the const-correctness I'm calling for elsewhere.
* Chaining of the buffers is made using singly linked list. | ||
* | ||
* Memory buffers can be allocated either from heap or from memory pools. Heap buffers are always contiguous. | ||
* Memory pool buffers may be either contiguous or chained depending on allocation size. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to distinguish what you call "buffer" here from the "emac_mem_buf_t". I would suggest you use "buffer" and "buffer chain", and say whether calls work on a buffer or an entire chain. Then the EMAC API passes a chain up or down.
Updated commits based on comments. |
@mikaleppanen destination branch updated, not certain why commits are still shown here that are already there |
Thanks, I changed base branch to master and back to feature-emac and the github updated the commit list. |
Please review CI (travis and jenkins) both report failures (travis docs and jenkins compiler error) |
Updated lwip memory manager to support pool allocation alignment. Updated K64F and STM ethernet drivers. |
@mikaleppanen Can you rebase this PR, I rebased the branch to resolve some issues that were affecting this PR |
@0xc0170 I rebased the PR |
Travis - docs failure (doxygen needs fixes), and jenkins CI - can't find a header file |
Please review the jenkins failure (one device fails to connect, the other 2 are regarding missing declarations) |
Updated commits. Looks like only cellular MTS_DRAGONFLY_F411RE is failing. @kjbracey-arm is it expected that with the current changes the cellular fails, and it will be updated later? |
Updated also cellular for MTS_DRAGONFLY_F411RE . Now that is also building. Rest of the build errors are from drivers that are not ported yet to new emac interface. |
Added a commit that adds set preferred alignment, copy to buffer and copy from buffer methods to memory manager. |
@mikaleppanen Let us know when this is ready for review by modifying the initial comment. Thanks! |
@0xc0170 @kjbracey-arm @SeppoTakalo This pull request is ready for review. |
.mbedignore with named files seems not to work gnuarmeclipse exporter, so changed the ublox wifi sdk directory .mbedignore to just contain asterisk. Now it should generate the eclipse project correctly. |
/morph build |
Build : SUCCESSBuild number : 1099 Triggering tests/morph test |
Exporter Build : SUCCESSBuild number : 777 |
Test : SUCCESSBuild number : 907 |
/morph uvisor-test |
We might need to rebase (uvisor json CI file was recently updated to resolve the errors we are seeing here). Please review after another CI run (I've retriggered it just now) |
@0xc0170 Correct, rebase is needed for uVisor CI update. |
ee8191f
to
5636fd9
Compare
instead of old memory interface.
Rebased the branch. |
/morph build |
Build : SUCCESSBuild number : 1114 Triggering tests/morph test |
Exporter Build : SUCCESSBuild number : 792 |
Test : SUCCESSBuild number : 929 |
Description
READY FOR REVIEW
EMAC memory manager changes.
Status
READY FOR REVIEW
Migrations
YES
#5558
Related PRs
List related PRs against other branches:
Todos
Deploy notes
Steps to test or reproduce