[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