HEAP size/heapless?

[lestofante]

Is it possible to run without usage of HEAP? this would be the only thing using heap in my application, and it would add some serious consideration.
And if HEAP is mandatory, what control its size/utility?

i was trying to test how fast i can write with something as (on a stm32f429zi baremetal)

while (1){
  int max = 100;
  while (mg_send(client, msg, sizeof (msg) -1) && max--)
    ;//next
  mg_mgr_poll(&mgr, 0);
  delay(xxx);
}

I played around with different HEAP size and MG_IO_SIZE with different ms delays, but the throughput seems to be related on how fast i call mg_mgr_poll() rather than HEAP buffer size;
I was expecting that higher delay with higher HEAP would maintain the throughput as the output of messages seems to be handled by DMA.
Am I missing something?
I am using MG_ENABLE_TCPIP=1 MG_ARCH=MG_ARCH_NEWLIB MG_ENABLE_CUSTOM_MILLIS=1 MG_ENABLE_CUSTOM_RANDOM=1 MG_IO_SIZE=512 MG_ENABLE_DRIVER_STM32=1

edit: also i had to fix some missing include from the current release library, maybe i missed some setup step? I am not using the makefile but included in my app

[scaprile]

You build, you write code, you control your heap size. Mongoose calls calloc(), it does need a heap unless you write your own.
You don't need to call any delay function, we don't do that in our tutorials nor in our examples. The timeout parameter in mg_mgr_poll() is only relevant when using an OS. Please use Mongoose as explained in our documentation, we don't do what you are doing. Please follow the guidelines in the documentation
If you have an issue, please open an issue, we don't have missing includes and I don't understand what is a "current release library"

[lestofante]

this does not answer my initial concern. Let me try to be clearer

You build, you write code, you control your heap size

I control how much preallocate for HEAP, but how much does the library need? In my tests, increasing the heap size does not seems to impact the amount of data written in a poll() call

The timeout parameter in mg_mgr_poll() is only relevant when using an OS

I am not using a timeout. My expectation was that with big 10x buffer, i could decrease the loop time 10x and still get similar throughput, but that is not the case and i dont understand why; the actual transmission seems to be handled by DMA, and DMA interrupt, so i expect it would be independent from poll().

Also eventually the goal is to integrate with embOS, so i will probably have to dig a bit deeper to see how to FreeRTOS/Zephyr is implemented and replace with my needs

follow the guidelines in the documentation

they are very shallow, no explanation on MG_IO_SIZE or estimation on HEAP usage or bandwidth capability. For example I extracted those defines looking at various test, and the ST test does not even declare a HEAP in the linker file!

[scaprile]

The heap allocation depends on what you do, we can't estimate what you do.
You are doing things we don't do and Mongoose runs on several totally different environments, we can't estimate your throughput on your system with what you are doing.
If you are using UDP, data is sent right away.
If you are using TCP, mg_send() will write to an iobuf that will be resized as needed. Data will be sent on further calls to mg_mgr_poll() as TCP permits.
There is no "loop time" to adjust, just call mg_mgr_poll() as frequently as possible as all our examples do.

We don't limit the heap memory usage if you are using our baremetal example for Newlib:

mongoose/examples/stm32/nucleo-f429zi-make-baremetal-builtin/syscalls.c

Lines 11 to 22 in ed54b60

	void *_sbrk(int incr) {
	extern char _end;
	static unsigned char *heap = NULL;
	unsigned char *prev_heap;
	unsigned char x = 0, *heap_end = (unsigned char *)((size_t) &x - 512);
	(void) x;
	if (heap == NULL) heap = (unsigned char *) &_end;
	prev_heap = heap;
	if (heap + incr > heap_end) return (void *) -1;
	heap += incr;
	return prev_heap;
	}

[lestofante]

The heap allocation depends on what you do, we can't estimate what you do.

I am trying to optimize for throughput at different loop speed, to get a feel what is possible at what resource cost.

I expect that slowing the loop 50%, but increasing the buffer 50%, should give me roughly the same thoughput. This is not happening and I dont understand why.

If you are using TCP, mg_send() will write to an iobuf that will be resized as needed. Data will be sent on further calls to mg_mgr_poll() as TCP permits.

Is is gonna send only one packet per poll()? that explain why it is not fast, there is a hard limit based on the packet MTU. Since the library seems to already use DMA ready interrupt, would it be possible to call some form of poll() in the ISR?

We don't limit the heap memory usage if you are using our baremetal example for Newlib:

yep, never seen that approach with no heap or stack declaration in the linker script

[scaprile]

Our current implementation of the stack will only send one segment on each iteration. That might change in the future, or not.
From the docs

NOTE: Since Mongoose's core is not protected against concurrent accesses, make sure that all mg_* API functions are called from the same thread or RTOS task.

That means you can't call mg_mgr_poll from main context and interrupt context at the same time

[lestofante]

Our current implementation of the stack will only send one segment on each iteration

thanks, that is a precious info, both to understand the maximum throughput in different configuration and HEAP usage

About HEAP usage, i took a look at the raw TCP mode and my finding are the following:
mg_tcpip_if contains most of the buffer, in recv_queue and tx.
Interestingly recv_queue initial size can be controlled by setting mif.recv_queue.size before mg_tcpip_init;
So my idea would be to change so i set recv_queue/tx buf and size to my static buffer, and if the buf are non-null (or maybe a compilation option is better) the allocation in mg_tcpip_init() skipped.
This leave with socket TX/RX, I think the number of max socket will be hard coded and mayeb ill use a fixed buffer poll.
As quick fix for allocation, instead of changing all the reallocation, I will make sbrk() fail.

Eventually is there any interest to have such changes upstream, and if yes, what would be the preferred way to do it?

[scaprile]

Perhaps you might want to go low-level and use long mg_io_send(struct mg_connection *c, const void *buf, size_t len);, which will send one frame per call. This might save you a lot of work. This is the function that gets ultimately called on every mg_mgr_poll() run when there is outstanding data to be sent

You may send a PR if you want, though I personally don't think we would go that way.