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

[Frédéric Bernon]

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

Some statistics I get about "redesign socket api". I join some part of the
code I patch to test that, but it's not a "patch file" (just some part to
show differences).

The test is based on a simple "while(1) sendto( s, data, 1458, 0, (struct
sockaddr *)&saRemote, sizeof(saRemote));" (using a measure performance tools
for NXP, a little bit intrusive, so, these stats are more to give you some
ideas of gain)...
 
CURRENT CVS:
Statistics: a lwip_sendto take ~0.204ms, the udp_sendtto part
~0.074ms/0.204ms

SOLUTION1: "always use netconn_sendto, but add a global mutex to replace
mbox"
Statistics: a lwip_sendto take ~0.117ms, the udp_sendtto part
~0.074ms/0.117ms

SOLUTION2: SOLUTION1 patchs+"directly use udp_sendto, and the global mutex"
Statistics: a lwip_sendto take ~0.076ms, the udp_sendtto part
~0.074ms/0.076ms

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). For
sockets layer user, we could also gain an independancy from netconn (like in
solution2): we could avoid netbuf use, api_msg preparation, and we could
reduce the footprint.

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

Comments ? Atte, Simon, I will be interested about stats with such patchs...





(file #12864)
    _______________________________________________________

Additional Item Attachment:

File name: API Layers measures.txt        Size:4 KB


    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message posté via/par Savannah
  http://savannah.nongnu.org/