lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] Don't trust ST drivers (was: very poor performance of httpd


From: Indan Zupancic
Subject: [lwip-users] Don't trust ST drivers (was: very poor performance of httpd)
Date: Wed, 19 Aug 2020 10:58:03 +0200

Hello Trampas,

 

The ST provided ethernet drivers for STM32H7 are (were?) buggy, and even more so the lwIP ethernet driver they provided.

This should be common knowledge by now, the internet is full with people having weird problems.

 

Among other issues, they tell the DMA it can re-use the buffers while lwIP hasn't processed them yet.

(Because they made it zero-copy without understanding what that implies.)

 

This means that if you are using the DMA buffers directly as pbufs then they may be overwritten if new packets arrive too quickly.

I strongly urge you to check if they fixed these issues in the driver you are using.

 

Some more details at:

 

https://community.st.com/s/question/0D50X00009q5WkDSAU/i-may-have-found-an-error-in-the-stm32h7-ethernet-driver-when-receiving-multiple-frames

https://community.st.com/s/question/0D50X00009yFPbYSAW/assertion-pbuffree-pref-0-failed-at-line-747-in-pbufc-while-using-lwip?t=1549359109339

 

We rewrote the whole lwIP ethernet driver to fix all the issues. We do use cached buffers for DMA, but issue cache

maintenance instructions to make sure everything is okay. (Make sure everything is cache line aligned though!)

We don't use zero copy because we are receiving and sending lots of small packets per second. Copying them as

quickly as possible is much more efficient for memory usage.

 

Alister also tried to fix all the issues and rewrote the driver too, but with keeping it zero copy I believe:

 

https://community.st.com/s/question/0D50X0000C6eNNSSQ2/bug-fixes-stm32h7-ethernet

 

I do not know what the current ST provided driver status is, maybe they fixed everything by now, including the HAL bugs.

If they did then they probably used Alister's code. Our code is rock solid, so I haven't looked at the newest ST code yet.

 

Best regards,

 

Indan Zupancic

 

 

 

TT Vasumweg 150  |  1033 SH Amsterdam  |  The Netherlands

Phone: + 31 [0]20 482 56 32  |   Fax: + 31 [0]20 482 00 77  |  Email: indan.zupancic@mep-info.com

 

From: lwip-users <lwip-users-bounces+indan.zupancic=mep-info.com@nongnu.org> On Behalf Of Trampas Stern
Sent: Tuesday, 18 August 2020 17:33
To: Mailing list for lwIP users <lwip-users@nongnu.org>
Subject: Re: [lwip-users] [EXTERNAL MAIL] very poor performance of httpd

 

So many chips use DMA for the MAC.  I had to put the LWIP Pbuf in a non cached section of RAM on an M7 to work. Specifically the M7 data cache was causing problems polling for when DMA was done as DMA wrote to SRAM but the processor was reading the cached version of SRAM.   Often when you need to add magical delays or debugging makes a difference it is either a caching problem or volatile data access being done incorrectly. 

 

Trampas

 

On Tue, Aug 18, 2020 at 11:27 AM Sachs, Nico <nico.sachs@trumpf.com> wrote:

Hi Felix,

I've also got very similar issues with Stm32F7,
It's somehow due to bugs in STMs HAL libraries.
I ended up with a quick fix which just waits a little before the packet gets sent out within low_level_output(...).
I had this one:

//dirty solution
for(uint32_t i = 0; i < 40000; i++) __nop();
/* Prepare transmit descriptors to give to DMA */
HAL_ETH_TransmitFrame(&heth, framelength);

If you access the page with chrome and display developer information, you can see the load times of your page. And there I've seen that after a timeout of 2seconds the files are getting requested again and then it works.

Also use Wireshark to spot what's going on.

This quick fix might not help in your case.

Cheers


-----Urspr√ľngliche Nachricht-----
Von: lwip-users <lwip-users-bounces+nico.sachs=trumpf.com@nongnu.org> Im Auftrag von Felix Frey
Gesendet: Montag, 17. August 2020 15:41
An: lwip-users@nongnu.org
Betreff: [EXTERNAL MAIL][lwip-users] very poor performance of httpd

Hi,

I've running an application on a STM32F429 using LwIP 2.0.3 and it's httpd.
Basically it works fine, however the performance of the httpd is very poor.

When the browser does a http request for a total of five files (statically linked) with a total amount of 40kB, it takes about 5sec to complete the request.
It seems like the httpd gets stalled.
In the log I can see several of the entrys below:
-----
00006.560: http_poll: pcb=0x2000d7b8 hs=0x2000db08 pcb_state=ESTABLISHED                                             
00006.560: http_poll: try to send more data                                                                           
00006.560: http_send: hs=0x2000db08 pcb=0x2000d7b8 left=22030                                                         
00006.560: Trying to send 0 bytes                                                                                     
00006.560: Sent 0 bytes                                                                                               
00006.560: send_data end.                                                                                             
00006.560: tcp_output
-----
This is repeated every 500ms for about 2sec until sending moves on.
It looks like it simply doesn't anything during this time. Why??

My memory settings are:
#define MEM_LIBC_MALLOC 1
#define MEMP_NUM_TCP_PCB 8
#define MEMP_NUM_PBUF 32
#define TCP_MSS 1460
#define TCP_WND 2920

I've already played with configuration settings, however, it didn't change a lot.
Can anybody explain this behaviour or even help to improve it?

Thanks in advance.
Felix

_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


reply via email to

[Prev in Thread] Current Thread [Next in Thread]