Howdy, The ESP32 leverages an implementation of the FreeRTOS environment. As such, a good assumption of meanings and validity of parameters can come from reading/studying the FreeRTOS documentation. If we look here:

https://www.freertos.org/a00125.html

We will find the documentation on the parameters called usStackDepth. It doesn't appear to need to be 2^10 aligned. The only note is that the size is measured in units of stack width.

In FreeRTOS, when a task is created, we declare how much stack should be available to that task. By design, the goal is not to run out of stack at run-time. Thus the storage for stack is pre-allocated for the task from heap.

This means that the concept of a "whole stack size" in ESP32 isn't useful. Instead, think of a freshly started ESP32 application. It will have a heap available to it and using another API we can ask the size of the heap. We can create as many tasks instances as we like as long as the stacks for each will fit within the available heap space minus overheads.

Actually in this case we vary from vanilla FreeRTOS in one small way. In FreeRTOS the stack size parameter is usually given in words, but in ESP-IDF we give it in bytes.

There are no other restrictions on stack size. We tend to use multiples of 512/1024 bytes because it's easy to reason about them in terms of "KB of RAM", but that's the only practical reason. I suspect sometimes developers like using powers of 2 because it sounds more "computer sciencey", as well. ;)

(Actually, there's one other reason - the xtensa processor aligns each stack frame to 16 bytes. So if the stack size isn't a multiple of 16, the remaining 1-15 bytes at the end will be wasted as a stack frame can't fit there.)

And another question: what is the whole stack size in esp32?
In my program where many tasks as well as BLE and WiFi used, there is not enough memory for curl (I use post requests.

When each task is created, its stack memory is allocated from the heap (with the requested size). The heap is all of the DRAM which is not statically allocated by other parts your program, so the free size will depend on your exact program.

A short summary of the total heap is logged when you boot, ie:

I (472) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM
I (478) heap_init: At 3FFDB590 len 00004A70 (18 KiB): DRAM
I (484) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (491) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (497) heap_init: At 40092ACC len 0000D534 (53 KiB): IRAM

(Heap has different types as is not entirely contiguous, but all of DRAM & D/IRAM can be used for task stacks.)

To get information about free heap at runtime, you can call a function: https://esp-idf.readthedocs.io/en/latest/api-reference/system/heap_debug.html#heap-information

Not sure how libcurl allocates memory. If it's really running out of stack (ie you get a stack overflow error), then you can increase the stack size to the task which is running out. If it's running out of heap (ie malloc() fails), then you need to look at ways to free up heap.

BTW, for further reference please post questions like this (which aren't an issue in ESP-IDF itself) over at https://esp32.com