Re: [lwip-devel] Core locking (Tasks #6935 and #6994) + some questions

[address@hidden]

address@hidden wrote:
> Hello,
>
> I am currently working on a design that enables strict priority
> queuing (based on TOS) in the tcpip thread. My current plan is to  
> introduce three more input queues and make the thread always process  
> the packet with
> the highest priority. I am wondering about the status of the core
> locking feature,
I thinks it's there hasn't been much work on this, lately, but it kind 
of works.
The problem with the current implementation (actually, this is a 
limitation in the tcp layer) is that you always have to lock the full 
stack, i.e. on thread processing a TCP packets keeps the other thread 
from processing a UDP packet. Therefore, the locking feature currently 
is only providing better performance (no thread change on send), not 
better priority handling!
>  and if you intend to keep both message passing and  
> core locking available in future versions.
Why not, the tcpip_thread is running anyway (to process input packets 
and maybe timers). The problem would be you would have to implement 2 
different netconn layers to access it that way...
>  I read the discussion in  
> task 6935, but couldn't access 6994.
>   
This is private to the lwIP group, although I don't know why. Maybe to 
prevent users from being confused...
> Some other questions:
>
> Function call VS macro, tcpip_apimsg:
> This was mentioned in task 6935, but I don't understand why you have  
> three of the netconn functions using tcpip_apimsg() directly, and the  
> remaining ten using the macro.
>   
I think that was because do_delconn, do_close and do_connect might 
require a thread change: the action they take aren't completed directly 
(connect: wait for answer from remote host; close can be delayed until 
the last packet is sent; delconn also closes). Therefore, you cannot 
just lock and execute the function but you have to wait for it to complete.
> Control flow in tcpip_thread:
> Are any of the TCPIP_MSG_* messages sensitive to timing? If possible I  
> would like to keep the internal messages at a lower priority than the  
> top priority message traffic (to enable WCET analysis).
>   
None that I know of. You only have to make sure you don't enqueue too 
many incoming packets on any queue (tcpip_thread incoming queue or 
netconn rx queue) while not processing the control messages (lwIP is/was 
kind of picky about full mboxes...).
> I made diagrams of function calls in UDP Rx and Tx using the  
> sequential API, I would appreciate it if anyone could have a quick  
> look at them and tell me if I got it right :)
> http://folk.ntnu.no/steinar/lwip/Rx.png
> http://folk.ntnu.no/steinar/lwip/Tx.png
>   
At least for me, the links don't work!
> I also intend to write a unit test for the tcpip_thread using check. I  
> can post it later if you are interested.
>   
Definitively interested! We started discussing unit tests in task #7930.

Simon