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

[Atte Kojo]

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
APIs.

> 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:

  <http://savannah.nongnu.org/task/?6935>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/