[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [task #6935] Problems to be solved with the current socket/

From: Atte Kojo
Subject: [lwip-devel] [task #6935] Problems to be solved with the current socket/netconn API
Date: Mon, 28 May 2007 08:40:30 +0000
User-agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.6 (like Gecko)

Follow-up Comment #10, task #6935 (project lwip):

> Conclusion: from current CVS code, it seems we can get easily a very
important gain of performance (from 0.204ms to 0.076, so, a ratio ~2.7).
Wow, that's impressive. Seems that at least on your platform using mboxes
alone consumes about half of the time required to send a packet. Do you have
the possibility to do even more detailed analysis. I at least would be
interested in knowing where the stack spends the ~100 extra milliseconds when
using mboxes.

It seems that just replacing mboxes with a giant mutex one could get a nice
peformance gain (~2) without doing any extensive changes to the existing

> But some problems I see with the global mutex solution: it a task with a
"low" priority lock the core to do any action (a send by example), and if
others tasks in the system with higher performance run, and often preempt it,
the global perf of the stack can decrease (because the perf is not only based
on the tcpip_thread priority, but on the time during the core is locked).
But isn't this actually desirable in some situations? Now even if the low
priority task generates a lot of network traffic it won't disturb higher
priority tasks when they don't use the stack. And with a mutex supporting
priority inheritance, priority inversion even isn't a problem.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]