What is limiting the UDP Rx?

[Yoschii97]

Hey folks. My question up there is probably a bit vague.

I'll try to formulate it more precisely and what I've done so far.

So first of all, I don't use RTOS.

I have a few data mapping and sending functions in my main loop. Actually, I should also put MX_LWIP_Process() there to check whether I have received a new UDP packet. To make this somewhat periodic, MX_LWIP_Process() is called in a timer interrupt at 50kHz.

It could be that I receive a flood of data via UDP and have to buffer them away. So I#m currently testing this with a Python script on a Raspberry Pi which simply sends me 150x 6Byte data in a UDP message as fast as it can.

At the moment everything works fine and i'm able to process the Data.

But from 195x 6Byte data I suddenly miss packets, so my recv_callback apparently did not trigger. (I checked its, its gotten only called 191times)(and i checked if the pi actually send 195x a package, he does)

I assume that even if MX_Process () is not executed, UDP packages will be received and buffered away somewhere ...

But where? Where is the memory made free?

Can I allocate more?

I want to be able to give a guarantee like "I can save as many bytes or packets for a short time without having processed them in my recv_callback"

Heres the lwipopts.h ->

/* STM32CubeMX Specific Parameters (not defined in opt.h) ---------------------*/
/* Parameters set in STM32CubeMX LwIP Configuration GUI -*/
/*----- WITH_RTOS disabled (Since FREERTOS is not set) -----*/
#define WITH_RTOS 0
/*----- CHECKSUM_BY_HARDWARE enabled -----*/
#define CHECKSUM_BY_HARDWARE 1
/*-----------------------------------------------------------------------------*/
 
/* LwIP Stack Parameters (modified compared to initialization value in opt.h) -*/
/* Parameters set in STM32CubeMX LwIP Configuration GUI -*/
/*----- Default value in ETH configuration GUI in CubeMx: 1524 -----*/
#define ETH_RX_BUFFER_SIZE 1524
/*----- Default Value for LWIP_DNS: 0 ---*/
#define LWIP_DNS 1
/*----- Default Value for MEMP_NUM_UDP_PCB: 4 ---*/
#define MEMP_NUM_UDP_PCB 255
/*----- Default Value for MEMP_NUM_TCP_PCB: 5 ---*/
#define MEMP_NUM_TCP_PCB 1
/*----- Value in opt.h for NO_SYS: 0 -----*/
#define NO_SYS 1
/*----- Value in opt.h for SYS_LIGHTWEIGHT_PROT: 1 -----*/
#define SYS_LIGHTWEIGHT_PROT 0
/*----- Value in opt.h for MEM_ALIGNMENT: 1 -----*/
#define MEM_ALIGNMENT 4
/*----- Default Value for H7 devices: 0x30044000 -----*/
#define LWIP_RAM_HEAP_POINTER 0x30044000
/*----- Value supported for H7 devices: 1 -----*/
#define LWIP_SUPPORT_CUSTOM_PBUF 1
/*----- Default Value for PBUF_POOL_BUFSIZE: 592 ---*/
#define PBUF_POOL_BUFSIZE 512
/*----- Value in opt.h for LWIP_ETHERNET: LWIP_ARP || PPPOE_SUPPORT -*/
#define LWIP_ETHERNET 1
/*----- Value in opt.h for LWIP_DNS_SECURE: (LWIP_DNS_SECURE_RAND_XID | LWIP_DNS_SECURE_NO_MULTIPLE_OUTSTANDING | LWIP_DNS_SECURE_RAND_SRC_PORT) -*/
#define LWIP_DNS_SECURE 7
/*----- Value in opt.h for TCP_SND_QUEUELEN: (4*TCP_SND_BUF + (TCP_MSS - 1))/TCP_MSS -----*/
#define TCP_SND_QUEUELEN 9
/*----- Value in opt.h for TCP_SNDLOWAT: LWIP_MIN(LWIP_MAX(((TCP_SND_BUF)/2), (2 * TCP_MSS) + 1), (TCP_SND_BUF) - 1) -*/
#define TCP_SNDLOWAT 1071
/*----- Value in opt.h for TCP_SNDQUEUELOWAT: LWIP_MAX(TCP_SND_QUEUELEN)/2, 5) -*/
#define TCP_SNDQUEUELOWAT 5
/*----- Value in opt.h for TCP_WND_UPDATE_THRESHOLD: LWIP_MIN(TCP_WND/4, TCP_MSS*4) -----*/
#define TCP_WND_UPDATE_THRESHOLD 536
/*----- Value in opt.h for LWIP_NETIF_LINK_CALLBACK: 0 -----*/
#define LWIP_NETIF_LINK_CALLBACK 1
/*----- Value in opt.h for LWIP_NETCONN: 1 -----*/
#define LWIP_NETCONN 0
/*----- Value in opt.h for LWIP_SOCKET: 1 -----*/
#define LWIP_SOCKET 0
/*----- Value in opt.h for RECV_BUFSIZE_DEFAULT: INT_MAX -----*/
#define RECV_BUFSIZE_DEFAULT 2000000000
/*----- Default Value for LWIP_SNTP: 0 ---*/
#define LWIP_SNTP 1
/*----- Default Value for SNTP_MAX_SERVERS: 1 ---*/
#define SNTP_MAX_SERVERS 4
/*----- Default Value for SNTP_CHECK_RESPONSE: 0 ---*/
#define SNTP_CHECK_RESPONSE 2
/*----- Default Value for SNTP_COMP_ROUNDTRIP: 0 ---*/
#define SNTP_COMP_ROUNDTRIP 1
/*----- Default Value for SNTP_UPDATE_DELAY: 3600000 ---*/
#define SNTP_UPDATE_DELAY 60000
/*----- Value in opt.h for LWIP_STATS: 1 -----*/
#define LWIP_STATS 0
/*----- Value in opt.h for CHECKSUM_GEN_IP: 1 -----*/
#define CHECKSUM_GEN_IP 0
/*----- Value in opt.h for CHECKSUM_GEN_UDP: 1 -----*/
#define CHECKSUM_GEN_UDP 0
/*----- Value in opt.h for CHECKSUM_GEN_TCP: 1 -----*/
#define CHECKSUM_GEN_TCP 0
/*----- Value in opt.h for CHECKSUM_GEN_ICMP6: 1 -----*/
#define CHECKSUM_GEN_ICMP6 0
/*----- Value in opt.h for CHECKSUM_CHECK_IP: 1 -----*/
#define CHECKSUM_CHECK_IP 0
/*----- Value in opt.h for CHECKSUM_CHECK_UDP: 1 -----*/
#define CHECKSUM_CHECK_UDP 0
/*----- Value in opt.h for CHECKSUM_CHECK_TCP: 1 -----*/
#define CHECKSUM_CHECK_TCP 0
/*----- Value in opt.h for CHECKSUM_CHECK_ICMP6: 1 -----*/
#define CHECKSUM_CHECK_ICMP6 0

Thanks everyone for reading this :D

And sorry if this question is kinda .. stupid.

I tryed to research but couldnt find something useful i understand :C

[Pavel A.]

> I want to be able to give a guarantee like "I can save as many bytes or packets for a short time without having processed them in my recv_callback"

What you want is rather "I can get incoming packets in my recv_callback as fast as possible and save/queue the data for processing in background".

[TDK]

> a Raspberry Pi which simply sends me 150x 6Byte data in a UDP message as fast as it can.

I would imagine the ethernet hardware capabilities of an RPi to be greater than that of an STM32. Order of magnitude difference in clock speed. UDP is send and forget, so it's possible packets just can't be processed as fast as they're coming in. Just a guess. At some point, hardware is a limitation. Certainly the STM32 isn't going to handle constant 100 Mbps data along with the LWIP handling part of it.

[Yoschii97]

But unfortunately that doesn't help me to make a precise statement for the user "so much data can be received".

It would be enough for me if I can guarantee that the STM32H7 can call the recv_callback so often and return it immediately.

Without further processing the data. Some like that:

void udp_receive_callback(void *arg, struct udp_pcb *upcb, struct pbuf *p, const ip_addr_t *addr, u16_t port){
	pbuf_free(p);		// Deallokiere Buffer
}

So that I can make at least the statement: "The STM can receive that amount of Data" and to save/queue the data it needs a measured average of time x.

So the actual achievable Datarate is ...

You understand what i want ^^'?

English isn't me first language, so often i get trouble to get over what I want.

[Yoschii97]

I thought something like that. And wanted to ask with my post above "how much can the STM32 handle in the worst case of 100Mbit / s"?

So to go into your points .. how fast can the STM32 process UDP packets? And what are the hardware limitation?

[TDK]

> how fast can the STM32 process UDP packets?

I don't think you'll find a straightforward answer. The best I can see is to do characterization at different rates to see what the limit is.

Keep in mind the network devices can affect timing of data as well, so even if the computer sends them out at X packets/sec, they may be received by the STM32 more frequently than that at times.

I'm sure you realize it, but if every packet is critical, TCP is the better protocol.

[Piranha]

> I assume that even if MX_Process () is not executed, UDP packages will be received and buffered away somewhere ...

The Ethernet DMA and RAM is much faster than the network. Therefore the limitation is the Ethernet interface itself.

> how fast can the STM32 process UDP packets?

I have seen an STM32F76x processing 50k small packets per second with a 30% load. The processing was doing a few basic one cycle instructions per byte.

https://community.st.com/s/question/0D50X0000AhNBoWSQW/actually-working-stm32-ethernet-and-lwip-demonstration-firmware

[ravo]

Dear @Piranha 

I am also interested in sending small packet as fast as possible. I would like to access your link but the mentioned article could not be opened, could you correct link ?

Best Regards

Radim