Skip to content

gnrc_sixlowpan_iphc: refactor reception for #8511 #9484

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
Jul 26, 2018
Merged

gnrc_sixlowpan_iphc: refactor reception for #8511 #9484

merged 1 commit into from
Jul 26, 2018

Conversation

miri64
Copy link
Member

@miri64 miri64 commented Jul 3, 2018 •
edited
Loading

Contribution description

This refactors reception/decoding part of gnrc_sixlowpan_iphc to the more layered approach modeled in #8511. Since the reception part is already complicated enough I decided to divide send and receive up into separate changes.

Testing

To test I used the ping6 and udp {send|server} server command tests/gnrc_udp with different packet sizes and ports (including the NHC UDP compressed range 61616-61631), and also with IPHC (de-)activated with ifconfig 6 -iphc on samr21-xpro. I also tested several compile configurations with the following patch (and commenting out the corresponding iphc/frag lines):

diff --git a/tests/gnrc_udp/Makefile b/tests/gnrc_udp/Makefile
index 9496288..9b594ec 100644
--- a/tests/gnrc_udp/Makefile
+++ b/tests/gnrc_udp/Makefile
@@ -8,7 +8,10 @@ BOARD_INSUFFICIENT_MEMORY := calliope-mini chronos hifive1 microbit msb-430 msb-
 
 USEMODULE += gnrc_netdev_default
 USEMODULE += auto_init_gnrc_netif
-USEMODULE += gnrc_ipv6_router_default
+USEMODULE += gnrc_ipv6_ib_6lr
+USEMODULE += gnrc_sixlowpan_router
+USEMODULE += gnrc_sixlowpan_frag
+USEMODULE += gnrc_sixlowpan_iphc
 USEMODULE += gnrc_udp
 USEMODULE += gnrc_rpl
 USEMODULE += auto_init_gnrc_rpl

(just resolves the dependency)

Issues/PRs references

Depends on #9482 (merged) and #9483 (merged).

Adapts IPHC reception for #8511.

@miri64 miri64 added Area: network Area: Networking Type: cleanup The issue proposes a clean-up / The PR cleans-up parts of the codebase / documentation GNRC labels Jul 3, 2018
@miri64 miri64 requested a review from cgundogan July 3, 2018 13:21
@miri64 miri64 added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Jul 3, 2018
@miri64 miri64 force-pushed the gnrc_sixlowpan_iphc/enh/i8511-recv branch from 5126267 to 59daa1e Compare July 3, 2018 14:18
@miri64 miri64 added State: waiting for other PR State: The PR requires another PR to be merged first CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Jul 3, 2018
This was referenced Jul 3, 2018
Merged
Closed
@miri64
Copy link
Member Author

miri64 commented Jul 3, 2018

Also ping @A-Paul. I think this could be interesting regarding GHC.

@miri64
Copy link
Member Author

miri64 commented Jul 24, 2018

Note to self: adapt for rename solicited in #9483 (comment), when rebasing.

@miri64 miri64 force-pushed the gnrc_sixlowpan_iphc/enh/i8511-recv branch from 59daa1e to 2c6b1cf Compare July 25, 2018 09:56
@miri64
Copy link
Member Author

miri64 commented Jul 25, 2018

Rebased to and adapted for current master.

@miri64 miri64 added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR State: waiting for other PR State: The PR requires another PR to be merged first labels Jul 25, 2018
@miri64
Copy link
Member Author

miri64 commented Jul 25, 2018

(since both dependencies are merged this PR is not waiting for another PR anymore)

@miri64 miri64 force-pushed the gnrc_sixlowpan_iphc/enh/i8511-recv branch from 2c6b1cf to f6ecdc8 Compare July 25, 2018 16:14
@miri64
gnrc_sixlowpan_iphc: refactor reception for RIOT-OS#8511
69d9ecc 
This refactors reception/decoding part of `gnrc_sixlowpan_iphc` to the
more layered approach modeled in RIOT-OS#8511. Since the reception part is
already complicated enough I decided to divide send and receive up into
separate changes.
@miri64 miri64 force-pushed the gnrc_sixlowpan_iphc/enh/i8511-recv branch from f6ecdc8 to 69d9ecc Compare July 25, 2018 16:15
@miri64
Copy link
Member Author

miri64 commented Jul 25, 2018

Rebased again, since the merging of #9485 created a conflict.

cgundogan
cgundogan approved these changes Jul 26, 2018
View reviewed changes
Copy link
Member

@cgundogan cgundogan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code looks fine and verified that frag/iphc is still working. Tested on the testbed w/ and w/o compiling frag/iphc.

@cgundogan cgundogan added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Jul 26, 2018
@cgundogan cgundogan merged commit f03e52d into RIOT-OS:master Jul 26, 2018
@miri64 miri64 deleted the gnrc_sixlowpan_iphc/enh/i8511-recv branch July 26, 2018 10:57
miri64 added a commit to miri64/RIOT that referenced this pull request Oct 23, 2018
@miri64
gnrc_ipv6_ext: use send for forwarding with RH
fd3d59d 
Though this change might seem more complicated, it has the benefit, that
after RIOT-OS#9484 we don't have to assume that a received packet within IPv6's
receive function can be handed to the function pre-parsed, making that
function far less complicated (will be provided in a future PR).
miri64 added a commit to miri64/RIOT that referenced this pull request Oct 23, 2018
@miri64
gnrc_ipv6_ext: use send for forwarding with RH
0365e20 
Though this change might seem more complicated, it has the benefit, that
after RIOT-OS#9484 we don't have to assume that a received packet within IPv6's
receive function can be handed to the function pre-parsed, making that
function far less complicated (will be provided in a future PR).

Also this might give the forwarding via routing header a little
performance boost, as we now don't *receive* the packet first only to
forward it later-on.
This was referenced Oct 23, 2018
Merged
Merged
miri64 added a commit to miri64/RIOT that referenced this pull request Oct 25, 2018
@miri64
gnrc_ipv6_ext: use send for forwarding with RH
1fa21d6 
Though this change might seem more complicated, it has the benefit, that
after RIOT-OS#9484 we don't have to assume that a received packet within IPv6's
receive function can be handed to the function pre-parsed, making that
function far less complicated (will be provided in a future PR).

Also this might give the forwarding via routing header a little
performance boost, as we now don't *receive* the packet first only to
forward it later-on.
miri64 added a commit to miri64/RIOT that referenced this pull request Oct 25, 2018
@miri64
gnrc_ipv6_ext: use send for forwarding with RH
b505327 
Though this change might seem more complicated, it has the benefit, that
after RIOT-OS#9484 we don't have to assume that a received packet within IPv6's
receive function can be handed to the function pre-parsed, making that
function far less complicated (will be provided in a future PR).

Also this might give the forwarding via routing header a little
performance boost, as we now don't *receive* the packet first only to
forward it later-on.
miri64 added a commit to miri64/RIOT that referenced this pull request Nov 17, 2018
@miri64
gnrc_ipv6_ext: use send for forwarding with RH
adcc16e 
Though this change might seem more complicated, it has the benefit, that
after RIOT-OS#9484 we don't have to assume that a received packet within IPv6's
receive function can be handed to the function pre-parsed, making that
function far less complicated (will be provided in a future PR).

Also this might give the forwarding via routing header a little
performance boost, as we now don't *receive* the packet first only to
forward it later-on.
miri64 added a commit to miri64/RIOT that referenced this pull request Dec 6, 2018
@miri64
gnrc_ipv6_ext: use send for forwarding with RH
b530c1b 
Though this change might seem more complicated, it has the benefit, that
after RIOT-OS#9484 we don't have to assume that a received packet within IPv6's
receive function can be handed to the function pre-parsed, making that
function far less complicated (will be provided in a future PR).

Also this might give the forwarding via routing header a little
performance boost, as we now don't *receive* the packet first only to
forward it later-on.
crest42 pushed a commit to crest42/RIOT that referenced this pull request Dec 18, 2018
@miri64 @crest42
gnrc_ipv6_ext: use send for forwarding with RH
61c5384 
Though this change might seem more complicated, it has the benefit, that
after RIOT-OS#9484 we don't have to assume that a received packet within IPv6's
receive function can be handed to the function pre-parsed, making that
function far less complicated (will be provided in a future PR).

Also this might give the forwarding via routing header a little
performance boost, as we now don't *receive* the packet first only to
forward it later-on.
BytesGalore pushed a commit to BytesGalore/RIOT that referenced this pull request Jan 29, 2019
@miri64
gnrc_ipv6_ext: use send for forwarding with RH
6bb389f 
Though this change might seem more complicated, it has the benefit, that
after RIOT-OS#9484 we don't have to assume that a received packet within IPv6's
receive function can be handed to the function pre-parsed, making that
function far less complicated (will be provided in a future PR).

Also this might give the forwarding via routing header a little
performance boost, as we now don't *receive* the packet first only to
forward it later-on.
@miri64 miri64 mentioned this pull request Feb 11, 2020
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@cgundogan cgundogan cgundogan approved these changes

Assignees
No one assigned
Labels
Area: network Area: Networking CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Type: cleanup The issue proposes a clean-up / The PR cleans-up parts of the codebase / documentation
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@miri64 @cgundogan