This'll traverse the netif list on every call (in O(N) time). IMO, for something that might be called multiple times per packet, that's not acceptable. Think benchmarks having different results depending on the number of configured network devices.

Why not an extra field in netif_t for the numerical id (for netif_get_id()), and a mapping array (for netif_by_id())?

This'll traverse the netif list on every call (in O(N) time). IMO, for something that might be called multiple times per packet, that's not acceptable. Think benchmarks having different results depending on the number of configured network devices.

I don't think it will be called multiple times per packet. I expect netif_get_id() to be called at most once per end-point initialization and netif_get_by_pid() once in the translation.

Why not an extra field in netif_t for the numerical id (for netif_get_id()), and a mapping array (for netif_by_id())?

I try to prevent topping the number of network interfaces at compile time. We currently actively go away from that.

Or we do it like I proposed originally (see latest fixup). This would be O(1) but also relies on some assumptions (all netif_t instances can be distinguished by the same 16-bit address suffix and netif_get_id() is only called for existing network interfaces.

Ping?

Ping @leandrolanzieri @jia200x?

I don't think it will be called multiple times per packet. I expect netif_get_id() to be called at most once per end-point initialization and netif_get_by_pid() once in the translation.

If this is the case, it seems to me that the cleaner approach is the one proposed in 4ef741f.

I try to prevent topping the number of network interfaces at compile time. We currently actively go away from that.

+1!

I don't think it will be called multiple times per packet. I expect netif_get_id() to be called at most once per end-point initialization and netif_get_by_pid() once in the translation.

If this is the case, it seems to me that the cleaner approach is the one proposed in 4ef741f.

Okay, I reverted c3cab1c

IMHO you can squash.

I squashed the changes so far, but, and I know this PR was already ack'd, I got an idea, how to keep the id thing downwards compatible, when used with sock: Make the definitions introduced here weak and override them in GNRC with the PID equivalent (netif->pid for netif_get_id() and gnrc_netif_get_by_id() for netif_get_by_id(). Let me know what you think.

I tested if this works with the following patch

diff --git a/examples/gnrc_networking/main.c b/examples/gnrc_networking/main.c
index 6301f4291..3d5cc9c63 100644
--- a/examples/gnrc_networking/main.c
+++ b/examples/gnrc_networking/main.c
@@ -22,6 +22,7 @@
 
 #include "shell.h"
 #include "msg.h"
+#include "net/netif.h"
 
 #define MAIN_QUEUE_SIZE     (8)
 static msg_t _main_msg_queue[MAIN_QUEUE_SIZE];
@@ -35,11 +36,15 @@ static const shell_command_t shell_commands[] = {
 
 int main(void)
 {
+    netif_t *netif = NULL;
     /* we need a message queue for the thread running the shell in order to
      * receive potentially fast incoming networking packets */
     msg_init_queue(_main_msg_queue, MAIN_QUEUE_SIZE);
     puts("RIOT network stack example application");
 
+    while ((netif = netif_iter(netif))) {
+        printf("netif %i\n", netif_get_id(netif));
+    }
     /* start shell */
     puts("All up, running the shell now");
     char line_buf[SHELL_DEFAULT_BUFSIZE];

But now the ID is not predictable anymore.
I liked this PR because it enabled pid-independent IDs for interfaces.

Now it will again change based on what modules are used, so it can not be used to attach information to IDs on the board level.

But now the ID is not predictable anymore.
I liked this PR because it enabled pid-independent IDs for interfaces.

Now it will again change based on what modules are used, so it can not be used to attach information to IDs on the board level.

With the current approach however we can slowly phase over to that instead of having to change over in a huge, hardly testable, push.

IMHO: since sock is a very stable API, that is expected to be used outside of the main repo, this is the more desirable option.

But changing the behavior of netif_get_id() depending on what stack is used sounds like a bad idea.

How about leaving netif_get_id() as is and instead provide a stack-dependent wrapper function?

static inline int16_t gnrc_netif_get_id(const gnrc_netif_t *netif)
{
    return netif->pid;
}

static inline int16_t lwip_netif_get_id(const netif_t *netif)
{
    return netif_get_id(netif);
}

But changing the behavior of netif_get_id() depending on what stack is used sounds like a bad idea.

The fallback (or previous general approach) is also stack dependent, because it is dependent in which order the interfaces are initialized (which at the moment the stacks do).

How about leaving netif_get_id() as is and instead provide a stack-dependent wrapper function?

That would defeat the purpose of a generalized API used with sock. Because then we would need do something like this in the transition period:

#if IS_USED(MODULE_GNRC)
    int16_t id = gnrc_netif_get_id(netif);
#elif IS_USED(MODULE_LWIP)
    int16_t id = lwip_netif_get_id(netif);
#endif
    local_ep->netif = id;

Then I rather don't introduce this function at all until we are transition and splatter this all over the code base ;-P:

#if IS_USED(MODULE_GNRC)
    int16_t id = ((gnrc_netif_t *)netif)->pid;
#elif IS_USED(MODULE_LWIP)
    int16_t id = ((struct netif *)netif)->num;
#endif
    local_ep->netif = id;

Hm and what I was trying to do wouldn't work anyway since there is currently no stack-independent way to get the netif_t * corresponding to a netdev_t * 😕

Yes, we are still a bit away from compile-time-unique identifiers. But this was not the point of this PR anyway (this as the OP says is more a user-level API), but with this we might become closer.

Squashed

@benpicco @miri64 is this one still mergeable ?

IMHO, yes.

I give it another rebuild though.