lwip-users
[Top][All Lists]
Advanced

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

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


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

Hi Mario,

I have no experience with the F7, so I'm not sure. Judging by:

https://community.st.com/s/question/0D50X0000BOtfhnSQB/how-to-make-ethernet-and-lwip-working-on-stm32

It seems the H7 has more issues, but the F7 isn't perfect either.

Best is to do a thorough code review of the provided driver you are using and 
to test it under load.

As a rule of thumb, if the driver is trying to be zero copy it's almost for 
sure buggy.

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

-----Original Message-----
From: lwip-users <lwip-users-bounces+indan.zupancic=mep-info.com@nongnu.org> On 
Behalf Of Mário Luzeiro
Sent: Wednesday, 19 August 2020 17:24
To: Mailing list for lwIP users <lwip-users@nongnu.org>
Subject: Re: [lwip-users] Don't trust ST drivers (was: very poor performance of 
httpd)

Hi Indan,
thanks a lot for this, I will have a try once I got a chance.

I'm using a STM32F, do you think that your fix could also apply to this MCU?

Mario

________________________________________
From: lwip-users <lwip-users-bounces+mrluzeiro=ua.pt@nongnu.org> on behalf of 
Indan Zupancic <Indan.Zupancic@mep-info.com>
Sent: 19 August 2020 09:58
To: 'Mailing list for lwIP users'
Subject: [lwip-users] Don't trust ST drivers (was: very poor performance of 
httpd)

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

[cid:image001.gif@01D67613.7ADD54B0]


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<mailto: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<mailto: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<mailto:trumpf.com@nongnu.org>>
 Im Auftrag von Felix Frey
Gesendet: Montag, 17. August 2020 15:41
An: lwip-users@nongnu.org<mailto: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<mailto:lwip-users@nongnu.org>
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org<mailto:lwip-users@nongnu.org>
https://lists.nongnu.org/mailman/listinfo/lwip-users




reply via email to

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