drivers: ethernet: eth_stm32_hal: Modify RX thread creation

[marwaiehm-st]

This change will allow users to configure the Ethernet RX thread according to their specific real-time requirements.
Adding preemptive threading helps to reduce jitter and the impact of Ethernet traffic on real-time performance.

[KozhinovAlexander]

@marwaiehm-st Thank you for you contribution. The changes are looking very clean and understandable. Also the yield is huge.
I would suggest you to move this PR grom draft to opened state, afterwards all necessary reviewers shall be picked automatically.

Please also add following steps:

• Write down the behaviour of thread priority based on preemptive KConfig switch in coresponding KConfig of the driver itself here: https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/ethernet/Kconfig.stm32_hal#L48
• You described the changes done in the first message of this PR. Please describe additionally the problem and steps to reporduce it like you did it in your post already here: Real time performance impacted by STM32 Ethernet traffic #75813 (comment)
• Adding the link to discussion may be helpful: Real time performace impacted by ethernet traffic #75424

I am still fighting with some CAN bus linux driver fix matching zephyr's driver counterpart in my sparse private time :) Thus doing measurements will take me more time. But as soon as your PR changes the state there will be more people assigned, who maybe also could do network timing tests described by you.

Great work. Many thanks to you.

[decsny]

you should probably make a separate driver kconfig for this. If you think the two configs will most likely have the same value then you could default y if NET_TC_THREAD_PREEMPTIVE

[KozhinovAlexander]

you should probably make a separate driver kconfig for this. If you think the two configs will most likely have the same value then you could default y if NET_TC_THREAD_PREEMPTIVE

There is already a KConfig for hal_stm32_ethernet: https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/ethernet/Kconfig.stm32_hal Thus it is not necessary I think. Proper description of the behavior in help section of KConfig would be fine.

[decsny]

That's not what I'm talking about, I mean a Kconfig to say if the driver rx thread priority is preemptive, instead of coupling it to the net tc thread priority being preemptive

[KozhinovAlexander]

Oh, I see. It makes sense. Thanks. @marwa could you please add corresponding option?

[erwango]

you should probably make a separate driver kconfig for this.

I'm not sure why this would be required. ETH_STM32_HAL_RX_THREAD_PRIO is neutral.
And a STM32 specific symbol to reflect value of subsystem's one doesn't add much aside a possibility of misconfiguration.

[KozhinovAlexander]

I think it is more about NET_TC_THREAD_PREEMPTIVE

[marwaiehm-st]

Does it mean adding ETH_STM32_HAL_RX_THREAD_PREEMPTIVE to drivers/ethernet/Kconfig.stm32_hal ?

config ETH_STM32_HAL_RX_THREAD_PREEMPTIVE
    bool "STM32 Ethernet RX Thread Preemptive"
    default y if NET_TC_THREAD_PREEMPTIVE
    help
      Enable preemptive scheduling for the RX thread of STM32 Ethernet.

...and changing the thread creation?

Suggested change

	IS_ENABLED(CONFIG_NET_TC_THREAD_PREEMPTIVE)
	IS_ENABLED(CONFIG_ETH_STM32_HAL_RX_THREAD_PREEMPTIVE)

[erwango]

I think it is more about NET_TC_THREAD_PREEMPTIVE

Yes, my response was toward this proposal indeed.

[KozhinovAlexander]

Does it mean adding ETH_STM32_HAL_RX_THREAD_PREEMPTIVE to drivers/ethernet/Kconfig.stm32_hal ?

config ETH_STM32_HAL_RX_THREAD_PREEMPTIVE
    bool "STM32 Ethernet RX Thread Preemptive"
    default y if NET_TC_THREAD_PREEMPTIVE
    help
      Enable preemptive scheduling for the RX thread of STM32 Ethernet.

...and changing the thread creation?

Suggested change

	IS_ENABLED(CONFIG_NET_TC_THREAD_PREEMPTIVE)
	IS_ENABLED(CONFIG_ETH_STM32_HAL_RX_THREAD_PREEMPTIVE)

@decsny I think, it would be better, if you clarify it.

[decsny]

yes the last comment you have with the suggestion is what I meant would probably be a good idea, as the net tc thread is not the same thread as the one being made in the ST ethernet driver, so it seems like it would make sense to have a different set of configs for that thread specifically