gnrc_sixlowpan_frag: allow send of multiple datagrams simultaneously

[miri64]

Contribution description

For fragment forwarding I need to be able to send (and in case the packet is compressed also [re-]construct) fragments of multiple datagrams. Currently this is not possible, since the source for the datagram tag is always taken from the global variable _tag. However, by adding the tag to the gnrc_sixlowpan_msg_frag_t type we are able to allocate a datagram tag from _tag at an earlier point and use the new member to set the fragments datagram tag field from that.

I also piggy-backed some optimizations to the gnrc_sixlowpan_frag module, which results in this enhancement only to require 20 more bytes of code.

Testing procedure

gnrc_networking should still be able to ping between two 6Lo-capable nodes with large payloads.

Issues/PRs references

No dependencies, but provides basis for others:

[miri64]

#11068 is too experimental so it doesn't make any sense to try too get this into the release => post-poned.

[miri64]

Rebased to current master and moved compile configurations to net/gnrc/sixlowpan/config.h (see #11415)

[cgundogan]

The code looks good, tested on the iotlab testbed using 2 nodes. The normal operation still works. I then compiled with GNRC_SIXLOWPAN_MSG_FRAG_SIZE=2 and reduced the ping interval in order to get interleaving ping fragments.

With below configuration pinging works:

ping6 -c 100 -i 200 -s 1232 ...

With below configuration pinging does not work:

ping6 -c 100 -i 100 -s 1232 ...

I assume that with a payload of 1232 I trigger ~10 fragments with an average RTT of ~100ms.
While a pinging interval of 200ms yields almost 100% success, pinging with 100ms yields 0% success. I can't tell whether it's just because of a too small fragmentation buffer.

Nevertheless, the proposed change is sane and the default is to handle 1 datagram at a time anyways. ACK from my side.

[miri64]

The effect has nothing to do with the new feature. The same will be visible on master, as you are sending huge packages faster than the node can handle them (RTT for those pings alone is >100ms

[cgundogan]

The effect has nothing to do with the new feature. The same will be visible on master, as you are sending huge packages faster than the node can handle them (RTT for those pings alone is >100ms

yes, but I would expect at least some pings to succeed. I see 0% success.

[miri64]

Squashed

[miri64]

yes, but I would expect at least some pings to succeed. I see 0% success.

How could a ping succeed, if you are draining the pinged nodes resources in one instance? The "problem" is the new asynchronous ping here. It doesn't wait for a reply until it sends the next package, like the old ping did and thus makes such effects more visible. See also RIOT-OS/Release-Specs#121 for what is happening. Anyway, this is unrelated to this PR.

You won't be able to force the 6LoWPAN thread to send multiple datagrams just with one node. You need fragment forwarding to observe this.

[cgundogan]

You won't be able to force the 6LoWPAN thread to send multiple datagrams just with one node. You need fragment forwarding to observe this.

so it's currently not possible to test this new feature with this PR alone? Nevertheless, I confirmed that it at least does not break the current master's behaviour.

[cgundogan]

re-ACK

[miri64]

so it's currently not possible to test this new feature with this PR alone?

Yepp, that's why the testing procedures say

gnrc_networking should still be able to ping

;-)