#10488 (comment) and some discussions with @haukepetersen regarding Bluetooth LE got me thinking: How sensible is it to have one thread per interface? Especially with emerging new boards which have multiple network devices or with BLE where each established connection/pairing can (or even should) be abstracted as an interface, this sounds like a RAM explosion to happen. Also syncing between two threads when a multi-capable radio like the nrf52840 is switching between modes would also be quite a hassle.

In a short discussion with @haukepetersen we came up with the following draft for a concept:

• Interfaces are (GNRC-internally) not identified by a PID anymore, but the gnrc_netif_t pointer (taking discussions around a 64-bit support into account, we need to come up with an alternative solution for that, since demux_ctx - see below - only has 32-bit...).
  • ⇒ The PID member of gnrc_netif_t is replaced with a suitable identifier for user space identification (e.g. a running number).
• GNRC_NETTYPE_NETIF is redefined from being -1 to a value > GNRC_NETIF_UNDEF. This has the result, that GNRC_NETTYPE_NETIF would become a subscribable type via gnrc_netreg.
• gnrc_netif_t get's a gnrc_netreg_t member which the corresponding handler thread uses to subscribe itself to the (nettype, demux_ctx) tuple (GNRC_NETTYPE_NETIF, interface identifier).
• If someone wants to send to the interface, they set the interface identifier in the GNRC netif header of the packet and use gnrc_netapi_dispatch_send() to send it to (GNRC_NETTYPE_NETIF, interface identifier). This way only the corresponding handler thread for the network interface is receiving the packet.
• The corresponding handler thread of the network interface uses the interface identifier in the GNRC netif header to access the interface and uses its gnrc_netif_ops_t::send operation to pass it on to the network device (or alternative sending approaches ;-)).
• Grouping of interfaces could e.g. be done by MAC protocol ⇒ No mac protocol is one thread, contikimac another, etc.

This has the added benefit, that gnrc_netif would act much more like other GNRC modules, as it currently bypasses the abstraction layer provided by gnrc_netreg and only allows gnrc_netapi to directly use PIDs for addressing.

Another benefit is that we could get finally a proper loopback interface without much overhead, with gnrc_ipv6's thread being the handler for that interface (and its interface identifier being the NULL pointer ;-)).

Note that this just contradicts one concept in #9903: that the gnrc_netif_t variable would be stored on stack. If the user supplies the interface struct on _create(), a GNRC_NETIF_NUMOF-based approach is still possible, even necessary. So #9903 actually should be a step towards the goal of the issue of this discussion.

Also note, that with this approach multiple interface handler threads are still possible.

I don't know how much this interferes with #7736 and its idea to allocate the netdev's layers in the network interface thread. :-/