cpu/esp32: esp_wifi improvements and cleanups

[gschorcht]

Contribution description

This PR provides several improvements and cleanups that

• reduces packet loss rate
• increases stability
• provides code similarity with esp_wifi of ESP8266 for future code deduplication

In detail the PR provides the following changes:

1. Receive call back function _esp_wifi_rx_cb is called from WiFi hardware driver with a pointer to a frame buffer that is allocated in the WiFi hardware driver. This frame buffer was freed immediately after copying its content to a single local receive buffer of the esp_wifi netdev. The local receive buffer then remained occupied until the protocol stack had processed it. Further incoming packets were dropped.
   Very often, however, multiple consecutive WiFi frames are received simultaneously before the first is fully processed. Having the local receive buffer to hold only one received frame, led to a number of lost packets, even at low network load.
   Therefore, a ringbuffer of rx_buf elements was introduced which doesn't store the frames directly but only references to the frame buffers allocated in WiFi hardware driver. Since there is enough memory for a number of such frames, the frames buffers allocated in the WiFi hardware driver are no longer freed immediately, but are kept until the frame has been processed by the protocol stack. This leads to a much lower loss rate of packets.
2. Instead of having a send buffer as member esp_wifi netdev, a local variable is now used as send buffer. This avoids the need for a locking mechanism and reduces the risk of deadlocks.
3. Events of different types can be pending at the same time. Therefore it is not possible to use ascending identifiers for the presence of pending events. Rather, each event type has to be represented by one bit. Thes bits ORed identify all types of pending events. In the esp_wifi_isr function all pending events are then handled in one call. Otherwise, some events might be lost.
4. Parameter checks were replaced by assertions.
5. Some small cleanups.

Testing procedure

Compile and flash examples/gnrc_networking to one ESP32 node.

USEMODULE='esp_wifi' CFLAGS='-DESP_WIFI_SSID=\"ssid\" -DESP_WIFI_PASS=\"passphrase\"' make BOARD=esp32-wroom-32 -C examples/gnrc_networking flash

1. Simultaneously ping the ESP32 node from different terminals or machines with very high, but different rates and different payload sizes:

   term 1> ping6 <ipv6_address>%eth0 -i 0.001
   

   term 2> ping6 <ipv6_address>%eth0 -i 0.004 -s 1200
   

   term 3> ping6 <ipv6_address>%eth0 -i 0.008 -s 1392
   

   The loss rate should be 0 % for all pings.

   Compare with current master, where the loss rates is already 20 % with only one ping.

   term 1> ping6 <ipv6_address>%eth0 -i 0.08
   

   The reason is the missing ring buffer for simultaneous incoming WiFi frames.

2. Again, simultaneously ping the ESP32 node from different terminals or machines with high, but different rates and different payload sizes. Additionally, send UDP packets from the ESP32 node:

   term 1> ping6 <ipv6_address>%eth0 -i 0.02
   

   term 2> ping6 <ipv6_address>%eth0 -i 0.03 -s 1200
   

   term 3> ping6 <ipv6_address>%eth0 -i 0.04 -s 1392
   

   term 4> nc -6ul 12345
   

   esp32> udp send <ipv6_address of term4> 12345 "." 10000 10000
   

   Once the udp command has been finished, stop nc with

   term 5> killall -TERM nc
   

   and check the number of characters received by nc. It should be 10.000, that is 0 % loss rate. Also the ping commands should still have a loss rate of 0 %.

Issues/PRs references

Depends on PR #11947

[benpicco]

This looks good!
The esp32 can now keep up with even two computers flood-pinging it.

With ringbuffers you could even do without locking if you sacrifice one element. I thought tsrb would already provide a convenient implementation for that, but I don't see how it could guarantee integrity for records > 1 bytes.

Anyway, this is already a big improvement, we can always optimize it further in another PR if that's necessary.

[benpicco]

Just squash already

[benpicco]

Tested on esp32 with flood pings, dropped packets reduced significantly.

[gschorcht]

@benpicco Thanks for reviewing and testing.