Re: [lwip-users] TCPIP and MAC thread task priorities

[Noam Weissman]

Hi All,

This comes from my own experience with STM micro that has Cortex-M core 
Running with FreeRTOS. It does apply to STM9 etc...

TCP main task priority should be high priority. It should not be the highest 
priority but it should
not be lower than other tasks that consume lots of time share.

The most misunderstood issue is interrupt priority levels in Cortext-M and 
FreeRTOS.

First of all:
A lower number in Coretex means a higher priority while in FreeRTOS a higher 
number
Means a higher priority.

Secondly Cortex use a nesting interrupt and a smart level... Assume you set an 
interrupt to 
level 2 and try to run some critical section code from RS232 but that RS232 has 
an interrupt
level set at 5. 

What happens is that the interrupt 2 (higher) will never be masked because the 
issuer of the
Critical section runs at a lower interrupt level.

FreeRTOS has lots of sections like this one:

  portENTER_CRITICAL();
  {     
     // some code
  }     
  portEXIT_CRITICAL();


If you set your interrupt level to be higher priority than the FreeRTOS timer 
tick that part will never
Be masked and your critical section will not work as expected.

I had strange problems and only after understanding the above I stabilized my 
software.

I hope this is clear now.

BR,
Noam.


-----Original Message-----
From: lwip-users [mailto:address@hidden On Behalf Of Sylvain Rochet
Sent: Monday, February 27, 2017 1:02 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] TCPIP and MAC thread task priorities

Hi Wayne,

On Mon, Feb 27, 2017 at 01:56:24PM +1000, Wayne Uroda wrote:
> I was looking through my codebase recently (a mix of code from LPC 
> Open, and also a project I inherited) and I saw a comment which I want 
> to fact
> check:
> 
> /* TCPIP thread must run at higher priority than MAC threads! */
> 
> My software is using FreeRTOS. The Ethernet interrupt only signals a 
> semaphore which wakes up the "MAC" thread. This thread handles 
> incoming and outgoing packets on the ethernet hardware.
> 
> The comment implies that this MAC thread must run at a lower priority 
> than the TCPIP thread. I don't know who wrote the comment, or if it is 
> correct.
> This posting

"must" is wrong, there is no such requirement.


> http://lists.nongnu.org/archive/html/lwip-users/2010-03/msg00148.html
> 
> indicates that there may not be such a stringent requirement, and it 
> might even be advantageous to have the Ethernet task run at a higher 
> priority than the TCPIP thread, but I'm not sure if the same applies to a MAC 
> thread.

At first sight, if your TCPIP thread is busy handling packets from the message 
box there is little value of pushing more packets into it. But (there is always 
a but), if you do otherwise, if the TCPIP message box is full, you will enter a 
priority inversion condition and your RX thread will wait for a little while to 
queue the message or drop the packet.

It means having your RX thread with a higher priority helps your system to fill 
the TCPIP thread message box, this is not the case if your RX thread have a 
lower priority than the TCPIP thread.

So, I'm with Simon on that, your RX thread *should* have a higher priority than 
the TCPIP thread. Anyway, this is always the case for RX interrupt based 
systems.


Sylvain