Re: [lwip-users] Low Iperf performance of lwip 1.4.1 on STM32 and FreeRTOS

[Claudius Zingerli]

Dear Ella,

Well well... That's what I'm currently considering as well: A complete 
rewrite of the MAC driver. ST's code is definitely ugly, inconsistent 
and often seems to be copy-pasted from older code, but not really 
adapted to the new devices/functions.
I already fixed the thing you mentioned by ASSERTing l+q->len to be 
smaller than the buffer (ST's driver checks that somehow later by 
splitting one buffer into multiple buffers in 
ETH_Prepare_Transmit_Descriptors(...), but I'm not sure if that still 
works with the last chained DMA descriptor).

Before I write my own MAC driver, I wanted to get a benchmark running 
with the original code to compare it to LPCs Iperf benchmarks. They 
implemented a zero-copy MAC driver for LwIP that achieves almost line 
speed (at much slower clock rates than ST).
For my device: Ping round trip time is between 130us and 250us (1 Switch 
between Linux+STM32F407 running at 150MHz), but >0% packet loss, TCP is 
unreliable and UDP seems to work, but not benchmarked yet.

So: Any open (BSD/GPL), stable and optimally zero-copy MAC drivers for 
STM32F4x7+FreeRTOS available here? Maybe I can get some inspiration from 
ChibiOS's driver as they seem to have mostly not used ST code.

Regards

Claudius


On 6/23/2013 7:16 AM, ella wrote:
> The problem is not FreeRTOS but buggy and ugly STM32 netif driver. I have
> studied original driver provided by ST and had nothing but rewrite it.
>
> Just one example of wrong architecture of this driver. This is from
> low_level_output():
>
>      buffer =  (u8 *)(DMATxDescToSet->Buffer1Addr);
>      for(q = p; q != NULL; q = q->next)
>      {
>        memcpy((u8_t*)&buffer[l], q->payload, q->len);
>        l = l + q->len;
>      }
>
> Consider that buffers are allocated as
> extern uint8_t Tx_Buff[ETH_TXBUFNB][ETH_TX_BUF_SIZE];
> and are linked to chained DMA descriptors.
>
> If packet size bigger then ETH_TX_BUF_SIZE you are at potential danger of
> wrap around that is not treated in code. Same happens for RX flow. So no
> surprise you have a problems with big packets.
> And this is only one place, there is a number of others. There are also a
> few races.
> In short DO NOT USE THIS DRIVER.
>
>
>
>
>
> --
> View this message in context: 
> http://lwip.100.n7.nabble.com/Low-Iperf-performance-of-lwip-1-4-1-on-STM32-and-FreeRTOS-tp21579p21581.html
> Sent from the lwip-users mailing list archive at Nabble.com.
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users