Skip to content

Conversation

miri64
Copy link
Member

@miri64 miri64 commented Jun 27, 2017

Implements the forwarding table component of the NIB.

Depends on #7212.

This PR is part of the network layer remodelling effort:
PR dependencies

@miri64 miri64 added GNRC Area: network Area: Networking State: waiting for other PR State: The PR requires another PR to be merged first labels Jun 27, 2017
@miri64 miri64 added this to the Release 2017.07 milestone Jun 27, 2017
@miri64 miri64 requested a review from cgundogan June 27, 2017 12:45
@miri64 miri64 force-pushed the gnrc_ipv6_nib/feat/ft-component branch from 775cad7 to 3fc6298 Compare June 27, 2017 15:43
miri64 added a commit to miri64/RIOT that referenced this pull request Jun 27, 2017
miri64 added a commit to miri64/RIOT that referenced this pull request Jun 29, 2017
@miri64 miri64 force-pushed the gnrc_ipv6_nib/feat/ft-component branch from 89a9dff to fa71fc8 Compare June 30, 2017 16:05
miri64 added a commit to miri64/RIOT that referenced this pull request Jun 30, 2017
miri64 added a commit to miri64/RIOT that referenced this pull request Jul 4, 2017
miri64 added a commit to miri64/RIOT that referenced this pull request Jul 5, 2017
miri64 added a commit to miri64/RIOT that referenced this pull request Aug 11, 2017
@miri64 miri64 force-pushed the gnrc_ipv6_nib/feat/ft-component branch from 99a6afe to 5f89b17 Compare August 21, 2017 10:31
@miri64
Copy link
Member Author

miri64 commented Aug 21, 2017

Rebased to current master and current dependencies

@miri64 miri64 force-pushed the gnrc_ipv6_nib/feat/ft-component branch from 5f89b17 to 9b933fb Compare August 21, 2017 10:38
@miri64 miri64 force-pushed the gnrc_ipv6_nib/feat/ft-component branch from 9b933fb to 9a6b1ff Compare October 6, 2017 10:28
@miri64
Copy link
Member Author

miri64 commented Oct 6, 2017

Rebased to 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 State: waiting for other PR State: The PR requires another PR to be merged first labels Oct 6, 2017
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.

more comments to look at.

*
* @param[in] dst The destination.
* @param[in] ctx Packet that is supposed to go to that destination
* (is handed over to a reactive routing protocol if one exist
Copy link
Member

Choose a reason for hiding this comment

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

exists.

Copy link
Member

Choose a reason for hiding this comment

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

Why isn't this named pkt, but ctx, if the documentation says packet?

Copy link
Member

Choose a reason for hiding this comment

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

Can this be const probably?

Copy link
Member Author

Choose a reason for hiding this comment

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

Why isn't this named pkt, but ctx, if the documentation says packet?

Because it is the context of the forwarding step, but I don't care. I can call it pkt if you want.

Can this be const probably?

Maybe, but I'm not sure if this is guaranteed for every reactive routing protocol (even RPL adds stuff like routing headers to a packet and that's not even reactive).

Copy link
Member

Choose a reason for hiding this comment

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

Because it is the context of the forwarding step, but I don't care. I can call it pkt if you want.

Yes, please.

bool _nib_offl_is_entry(const _nib_offl_entry_t *entry)
{
return (entry >= _dsts) &&
(entry < (_dsts + GNRC_IPV6_NIB_OFFL_NUMOF));
Copy link
Member

Choose a reason for hiding this comment

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

_in_dsts()

DEBUG("nib: get match for destination %s from NIB\n",
ipv6_addr_to_str(addr_str, dst, sizeof(addr_str)));
for (_nib_offl_entry_t *entry = _dsts;
entry < (_dsts + GNRC_IPV6_NIB_OFFL_NUMOF);
Copy link
Member

Choose a reason for hiding this comment

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

_in_dsts()

int res = 0;

assert((dst != NULL) && (fte != NULL));
do { /* goto, but cleaner ;-) */
Copy link
Member

Choose a reason for hiding this comment

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

I don't think abusing a do { } while() construct is cleaner than goto. In this case you can return res anyway instead of using break. There's nothing important after the loop.

Copy link
Member Author

Choose a reason for hiding this comment

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

True to the last statement! and regarding "abusing" do { } while(0): it still provides a clear (stack-)frame structure, visible in the code. goto does not and can easily get out of hand because of that.

* }
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*
* @note The list may change during iteration, but no duplication of already
Copy link
Member

Choose a reason for hiding this comment

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

Are you sure the latter part of this sentence is true? What happens if an entry gets removed and then added (after 3 other additions). Then the same value would end up later in the list, right?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, that may happen. But then it is also wrong for nib_pl_iter() and nib_nc_iter(). Shall I remove it?

Copy link
Member

Choose a reason for hiding this comment

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

Shall I remove it?

Yup. No need to advertise features we cannot guarantee (:

@miri64 miri64 force-pushed the gnrc_ipv6_nib/feat/ft-component branch from 2a08ed2 to 02aa064 Compare October 6, 2017 14:05
@miri64
Copy link
Member Author

miri64 commented Oct 6, 2017

Rebased to current master

@miri64
Copy link
Member Author

miri64 commented Oct 6, 2017

Addressed comments.

@@ -483,6 +495,91 @@ _nib_offl_entry_t *_nib_offl_iter(const _nib_offl_entry_t *last)
return NULL;
}

bool _nib_offl_is_entry(const _nib_offl_entry_t *entry)
{
return (entry >= _dsts) && _in_dsts(entry);
Copy link
Member

Choose a reason for hiding this comment

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

isn't _in_dsts() also suppoed to check for >= _dsts?

Copy link
Member

Choose a reason for hiding this comment

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

you could probably remove _nib_offl_is_entry and use _in_dsts() everywhere

Copy link
Member Author

Choose a reason for hiding this comment

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

Nope. Since it is used as a loop-target this check wouldn't make sense / would be more expensive

Copy link
Member Author

Choose a reason for hiding this comment

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

But I can do the replacement for the cases where entry >= _dsts must also be true ;-).

Copy link
Member Author

Choose a reason for hiding this comment

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

(there is no such case in _nib-internal.c so all done ;-))

else {
_nib_ft_get(offl, fte);
}
return 0;
Copy link
Member

Choose a reason for hiding this comment

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

        else {
            _nib_ft_get(offl, fte);
        }
    }
    else {
        _nib_ft_get(offl, fte);
    }

Any chance to remove code duplication and / or level of nestedness?

Copy link
Member Author

Choose a reason for hiding this comment

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

I'll try something

Copy link
Member Author

Choose a reason for hiding this comment

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

Done

@miri64 miri64 force-pushed the gnrc_ipv6_nib/feat/ft-component branch from 9cc359a to 2cdae91 Compare October 6, 2017 20:51
@miri64
Copy link
Member Author

miri64 commented Oct 6, 2017

Rebased and addressed comments

@cgundogan
Copy link
Member

much better, please squash!

@miri64 miri64 force-pushed the gnrc_ipv6_nib/feat/ft-component branch from 2cdae91 to c60cacc Compare October 6, 2017 21:01
@miri64
Copy link
Member Author

miri64 commented Oct 6, 2017

Squashed

@cgundogan
Copy link
Member

cross another one off the list! (:

@cgundogan cgundogan merged commit d5c9644 into RIOT-OS:master Oct 6, 2017
@miri64 miri64 deleted the gnrc_ipv6_nib/feat/ft-component branch October 6, 2017 21:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants