[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-users] Performance issue: sending large buffers
From: |
Peter |
Subject: |
[lwip-users] Performance issue: sending large buffers |
Date: |
Thu, 21 Jul 2022 12:10:31 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
Hello Vincenzo
Like me you will waste half your life trying to get answers. Almost
nobody replies on lwip etc issues...
I suggest you post your lwipopts file. Also the ETH buffer settings in
one of the .h files
uint8_t Tx_Buff[ETH_TXBUFNB][ETH_TX_BUF_SIZE]
uint8_t Rx_Buff[ETH_RXBUFNB][ETH_RX_BUF_SIZE]
And your ethernetif_input() and low_level_input() functions.
I have just spent a few days on this stuff and started with
100kbytes/sec and now can do 1200kbytes/sec albeit with more RAM for
buffers, so I traded it off at 250kbytes/sec. I think one could get
2000kbytes/sec if one didn't have other constraints and had interrupt
driven RX (168MHz 32F417).
I am also polling in ethernetif_input() which is sub-optimal but works
ok, and there are lots of other tasks running.
Note that there are many issues which arise if e.g. you want the LWIP
API thread-safe. You need LWIP_TCPIP_CORE_LOCKING=1 and then you need a
separate set of mutexes around the low level stuff.
// RTOS task; runs for ever
void ethernetif_input( void * argument )
{
struct pbuf *p;
struct netif *netif = (struct netif *) argument;
// This mutex position is based on an idea from Piranha here, with the
delay added
//
https://community.st.com/s/question/0D50X0000BOtUflSQF/bug-stm32-lwip-ethernet-driver-rx-deadlock
do
{
sys_mutex_lock(&lock_eth_if_in);
p = low_level_input( netif );
sys_mutex_unlock(&lock_eth_if_in);
if (p!=NULL)
{
if (netif->input( p, netif) != ERR_OK )
{
pbuf_free(p);
}
}
else
{
osDelay(10);
}
} while(true);