This will help to track only what's wanted (ipv6, tpc, udp, else...) if
needed to.
Change-Id: I5c2e5e582db629b5d0e1cd98004f693c50f532a4
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
When zephyr receives a 15.4 frames it allocates 1 RX buf (nbuf) and 1
DATA (buf), and it gets queued on net stack for post processing.
Problem: receiving a lot of frames is just completely nominal and very
fast (timing is critical in radio, and the rx thread of the radio driver
has a high priority, much higher than net stack's rx post processing).
So guess what happens when CONFIG_NET_NBUF_RX_COUNT=10 though let's say
12 packets are coming in?
The RX buffer pools gets empty and soon the system hangs on getting a
newly allocated one.
This proper CONFIG_NET_NBUF_RX_COUNT tweak fixes the issue, however some
future work will reduce the need of so many RX meta buf:
- l2's recv could be called right away at net_recv_data, before queuing
the buffer for post-processing, but this could affects reception
timing on radio side, which is critical.
- An l2 pre-processing (in the middle of what current l2 recv does)
could be implemented, it would be technology depenedent (aka: not
mandatory on all l2) and could quickly decide what to do and at best
drop the whole, or at least drop the RX meta buf (frag would still be
kept). Let's see.
Jira: ZEP-1427
Change-Id: Ic75b02efa36e35b450c02b3e6439a8d73f03f839
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
As the native IP stack is now the default, there is no need
for corresponding Kconfig option.
Change-Id: I08e4992f540f928a2b7378e8803e634e38725348
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Tomasz Bursztyka