-
Notifications
You must be signed in to change notification settings - Fork 2.1k
gnrc_netif: don't allocate message queue on the stack #17905
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
After rebasing this on top of
The CC1101 driver seems to be roughly on par with the at86rf215 driver regarding stack consumption. So as it worked fine with the AT86RF215, it should work fine with the CC1101. |
Maybe, if the message queue size leads to problems, it is better to decouple it from the stack size, by making the message queue a |
You need one for every thread, so it can’t be static |
Ah, right! Sorry forgot about that ^^" |
Mhhh, but it could be part of the |
d4246ce
to
f35e6bd
Compare
I like the idea! |
Isn't that, what #18171 is for? |
f35e6bd
to
b1ea963
Compare
I like this one more as it also introduces a common |
Contribution description
The message queue of the netif was allocated on the netif stack, so we had to increase the netif stack size if we increase the message queue size.
CC110x was the only driver to get this right - add a new
GNRC_NETIF_STACKSIZE_DEFAULT
define so all drivers will get this right by default.To properly fix this, add the message queue to
gnrc_netif_t
.Testing procedure
This should not change the stack size except for one case:
cc110x
hadCC110X_EXTRA_STACKSIZE
set to(GNRC_NETIF_MSG_QUEUE_SIZE - 8) * sizeof(msg_t))
but the default message queue size is 16, adding(16 - 8) * 8
= 64 bytes to the stack.Leaving this at 8 for all drivers would effectively bump their stack by 8 messages.
Maybe this was a mistake or maybe
cc110x
really needs the extra 64 bytes of stack.@maribu might be able to give this a try and say if stack size is still sufficient.
Issues/PRs references