set up message queues for the IP and UDP thread #680
Conversation
cpu/native/irq_cpu.c
Outdated
There was a problem hiding this comment.
as far as I know static variables are always initialized to zero. so no need to do it explicitly. http://stackoverflow.com/questions/3373108/why-are-static-variables-auto-initialized-to-zero
msg_queue is defined but never used, hook it up so IP packets get queued instead of dropped when there is more than one. change the name to ip_msg_queue to avoid naming conflicts.
All other layers in the network stack use a msg_queue to not drop messages, which in this context represent packages. This finally fixes the random crashes when UDP network traffic is present. Turns out RIOT is not handling lost messages well.
|
64 * sizeof(msg_t) = 512. That's quiet a lot for most platforms. Can we reduce the size of the queue for non-native platforms? |
|
@OlegHahm do you think that 8 slots are enough? |
|
I think it heavily depends on the expected traffic pattern. In general I would vote for dimensioning these queues MCU dependent and fix/improve the handling of lost messages in 6LoWPAN. |
|
Maybe @benpicco can do some testing with different queue sizes and determine the best size. |
|
@OlegHahm let's merge this now and open up a ticket to keep in mind that the queue sizes in the sixlowpan stack need a refinement. |
|
as discussed in dev meeting, ACK, GO |
set up message queues for the IP and UDP thread
|
Created #773 |
When receiving many (UDP) packets RIOT crashes both on native and on the msba2.
It turns out that lost messages in the network stack are not handled well: If a queued message gets replaced by a new one, sender in
_msg_receivepoints to invalid data, RIOT crashes.This pull request works around this issue by hooking up the message queue in ip.c that is defined, but never used. It also introduces a similar queue for the udp thread, so now up to 64 packets can be received at roughly the same time before RIOT crashes.