1. Put some lwip udp rx/tx relating functions to IRAM
2. Put some wifi rx/tx relating functions to IRAMa
3. Reduce wifi dynamic malloc from 4 to 1 for each ebuf
4. Update iperf example accordingly
5. Update libphy.a to v383
Pointer tcpip_api_call *m should be converted to pppapi_msg* instead of pppapi_msg_msg*
in pppapi_do_ppp_set_default(), pppapi_do_ppp_free() and so on.
It solve this issue https://github.com/espressif/esp-idf/pull/1028
so there is no need to patch ip4.c because now netif_defauilt is setted correctly.
Also it prevents memory corruption when pppapi_free() is called.
* setsockopt(s, IPV6_ONLY, &one, sizeof(int)) will disable IPV6-only
mode. Incoming/outgoing IPV4 packets are dropped.
* Otherwise, sockets bound to IPV6_ANY_ADDR can receive unicast packets
for IPV4 or IPV6.
* sendto() a IPV6-mapped-IPV4 address on a UDP socket works correctly
(not supported for RAW or TCP sockets.)
* getaddrinfo() option AI_V4MAPPED is implemented.
As well as extending support to TCP & RAW, there is some potential improvement
to dropping incoming packets - the drop happens a bit late in the process and
there is no "ICMP port unreachable" response sent.
If the DNS request is dispatched and performed very quickly,
then it can complete before tcpip_callback() actually returns,
in which case we'll destroy the actual err_t error value passed
in the message. Use a local variable for the tcpip_callback
error code so that can't happen.
Resolves#269https://github.com/espressif/esp-idf/pull/269
1. Update wifi lib which contains ampdu and other optimizations
2. Add throughput code debug code
3. Other misc modification about throughput optimization
lwip: fix socket memory leak issue
1. Add socket memory leak debug counter
2. Fix TCP PCB leak issue
Currently ESP32 support maximum 16 TCP PCBs and all TCP PCB are allocated from heap memory. In some scenario, we may
have memory leak issue, for example, the application already created 16 TCP PCB, then it close 5 of them, because the TCP
state machine, the LWIP core may not free all the 5 TCP PCB immediately, maybe some is in TIME_WAIT status, some is in
FIN_WAIT_1 etc. Then the application try to malloc 17th TCP PCB (the application think they just create 12 because they already
close 5), memp_malloc() will return true because the heap is not out of memory, but actually we got 17 TCP PCB. When the
scenario repeat again and again (in our Audio application, it repeat more than 10000 times), more and more TCP PCB will be
created in the system, each TCP PCB require 200B, then memory leak happen (In Audio application, I saw more than 26 TCP PCB
are created, and 10*200=2K memory are leaked).
See merge request !223
1. Modify comments for esp_wifi_internal_tx
2. Fix delay time error in esp32_tx_flow_ctrl which is found in code review,
modify _wait_delay init value from 0 to 1
