STM32H7 Hal Ethernet Use of LWIP_MEMPOOL_DECLARE

[JRS]

Not sure if this is a bug or something I do not completely understand, but in the generated ethernetif.c file (HAL V1.9.0) there is the line:

LWIP_MEMPOOL_DECLARE(RX_POOL, 10, sizeof(struct pbuf_custom), "Zero-copy RX PBUF pool");

Which always uses, if I understand correctly, a fixed magic number of 10 for the pbuf-count. I would think that number should be tied to something like PBUF_POOL_SIZE. Or am I missing the point of this?

[Piranha]

The RX_POOL pool is used for allocating a pbuf_custom structures to couple those with the received data buffers from DMA. Therefore the number of the pbuf_custom structures should be exactly the same as the number of the DMA receive data buffers. There is no reason why this number should be anything else than the ETH_RX_DESC_CNT.

If the RX_POOL pool is larger than the DMA buffers (as in a default configuration), it will just waste some memory, but, if it is smaller, then it will limit the performance by making the ETH_RX_DESC_CNT > 10 configuration useless and waste significantly more memory than in the first case.

@Imen DAHMEN​, this is another bug for the ridiculously crippled H7 lwIP driver...

[alister]

I've a product with many connections of different service qualities (throughput, burstiness, etc), that are handled by tasks of different priorities. An Ethernet driver that dimensions rx buffers equal to rx descriptors and binds them is vulnerable to head-of-line blocking and is unsuitable in mine and other network products.

[Imen.D]

Hello @alister​ and @Piranha​ ,

Thanks for pointing out this issue.

I raised this internally to the appropriate team to take the necessary action.

Internal ticket ID 116209 is already created to solve this issue (PS: This is an internal tracking number and is not accessible or usable by customers).

Thank you for your contribution.

Imen

[Piranha]

We are talking about a zero-copy driver here, in which the data buffers are passed to the processing tasks, which release those after processing. Let's suppose the different tasks have not processed their data and released the data buffers yet, and we have run out of free data buffers. What's the point in having an additional free DMA descriptors or pbuf_custom structures if we have no more free data buffers to attach to those?

[Pavel A.]

> What's the point in having an additional free DMA descriptors or pbuf_custom structures if we have no more free data buffers

Looks like he lets the app to keep data buffers but release RX descriptors to recycle, and allocate more RX buffers.

This is why I wanted to separate the buffers & descriptors handling code from the "HAL" driver and make it part of "network stack" (so each "network stack" can have its own buffer management module). For the ST's advertised rework this is maybe way too radical.

[Piranha]

For a zero-copy driver there are no separate "RX buffers" and "data buffers" - those are the same buffers. If that is not the case, it implies a buffer copy operation and then that is not a zero-copy driver.

Your idea of splitting the code is good and that is exactly what I have implemented in my code since the beginning. I'll try to give more details on your topic soon. Also tomorrow I'll try to somewhat review and comment the ST's reworked ETH driver for H7.

[Pavel A.]

Finally someone decided to review the reworked driver. Thumb up.

[alister]

>For a zero-copy driver there are no separate "RX buffers" and "data buffers"

My changes to ST's ETH driver at https://community.st.com/s/question/0D50X0000C6eNNSSQ2/bug-fixes-stm32h7-ethernet is indeed zero-copy and it separates the RX buffers from the RX DMA descriptors.

Pointers to functions to allocate and free RX buffers are passed its HAL_ETH_Init.

Its function that readies the RX DMA descriptors calls the allocation function pointer to get an RX buffer.

Its RX buffers should be dimensioned greater than or equal its RX DMA descriptors.

[Imen.D]

Hello,

This problem is resolved in the STM32CubeH7 V1.10 MCU package.

Imen