gnrc_sixlowpan_frag: make aggresive override configurable#11442
Merged
cgundogan merged 1 commit intoRIOT-OS:masterfrom May 24, 2019
Merged
gnrc_sixlowpan_frag: make aggresive override configurable#11442cgundogan merged 1 commit intoRIOT-OS:masterfrom
cgundogan merged 1 commit intoRIOT-OS:masterfrom
Conversation
miri64
added
Area: network
cgundogan
approved these changes
May 24, 2019
| res = oldest; | ||
| if (GNRC_SIXLOWPAN_FRAG_RBUF_AGGRESSIVE_OVERRIDE || | ||
| ((now_usec - oldest->arrival) > | ||
| GNRC_SIXLOWPAN_FRAG_RBUF_TIMEOUT_MS)) { |
Member
There was a problem hiding this comment.
the suffix _MS of GNRC_SIXLOWPAN_FRAG_RBUF_TIMEOUT_MS is strangely chosen for a macro that holds microseconds .. however, this is unrelated to this PR. ACK!
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
2 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.
Contribution description
Currently, our 6Lo implementation always overrides the oldest reassembly buffer entry even if that one did not time out yet. While with larger reassembly buffers this can make sense to give newer datagrams precedence, smaller once suffer especially in multi-hop scenarios, where a router might reassemble multiple datagrams at once. As far as I am aware RFC 4944 does not mention this behavior, and I think I just adapted it from the legacy implementation back then. So it makes sense to make this aggressive behavior configurable.
Testing procedure
Try compile with
CFLAGS += -DGNRC_SIXLOWPAN_FRAG_RBUF_AGGRESSIVE_OVERRIDE=0andCFLAGS += -DGNRC_SIXLOWPAN_FRAG_RBUF_AGGRESSIVE_OVERRIDE=1both configurations should still work and when compiled with-DGNRC_SIXLOWPAN_FRAG_RBUF_SIZE=1larger datagrams should still be received with aggressive override deactivated when a node is pinged by two nodes while they are always not when aggressive override is activated.Issues/PRs references
None, but incorporated at the moment into #11068.