lwIP - A Lightweight TCP/IP stack - Tasks: task #6935, Problems to be solved with the...
You are not allowed to post comments on this tracker with your current authentication level.
task #6935: Problems to be solved with the current socket/netconn API
Submitter: | Simon Goldschmidt <goldsimon> | ||
Submitted: | Thu 24 May 2007 12:00:11 PM UTC | ||
Category: | None | Should Start On: | Thu 24 May 2007 12:00:00 AM UTC |
Should be Finished on: | Thu 24 May 2007 12:00:00 AM UTC | Priority: | 1 - Later |
Status: | None | Privacy: | Public |
Assigned to: | None | Percent Complete: | 0% |
Open/Closed: | Closed | Planned Release: | None |
Effort: | 0.00 |
Jump to the original submission
Mon 11 Jun 2007 06:26:57 PM UTC, comment #20: |
Simon Goldschmidt <goldsimon> |
Mon 11 Jun 2007 06:20:16 PM UTC, comment #19: Simon, ok to close it, and to be continue with https://savannah.nongnu.org/task/?6994 ?
|
Frédéric Bernon <fbernon> |
Sat 09 Jun 2007 11:16:25 AM UTC, comment #18: A design goal should be to easily disable code that is not used. While function-based linking helps with this, things like non-blocking sockets or the code needed for select is inside some functions and can only be left out by creating compile time switches for that. |
Simon Goldschmidt <goldsimon> |
Fri 08 Jun 2007 07:30:02 PM UTC, comment #17: Ok, I have check in. I hope this code can help to reach same performance in sequential API than in raw API...
|
Frédéric Bernon <fbernon> |
Mon 04 Jun 2007 10:13:39 AM UTC, comment #16: I'd consider this task relatively low priority, but if you're keen to experiment (and can keep it clean so easy to back out again if we decide this approach isn't worth it) then go ahead. |
Kieran Mansley <kieranm> |
Mon 04 Jun 2007 09:47:18 AM UTC, comment #15: Wrong copy/cut for the last part:
|
Frédéric Bernon <fbernon> |
Mon 04 Jun 2007 09:38:55 AM UTC, comment #14: To be able to continue this item and to integrate last patchs, I would like to add a way to enable the alternative communication feature with tcpip_thread (the global mutex).
|
Frédéric Bernon <fbernon> |
Fri 01 Jun 2007 08:29:58 AM UTC, comment #13: Another thing with the current socket layer (it's not true for netconn layer): "struct netbuf" is just used like a "wrapper" of a "struct pbuf" with addr & port fields. In socket layer, lot of netbuf functions are not used. And each time that a packet have to be exchange between socket layer & api_msg, there is an netbuf allocation, initialization & free.
|
Frédéric Bernon <fbernon> |
Tue 29 May 2007 05:23:48 PM UTC, comment #12: Some details about "where is spend the time"?
|
Frédéric Bernon <fbernon> |
Mon 28 May 2007 11:30:57 PM UTC, comment #11: >I at least would be interested in knowing where the stack spends the ~100 extra milliseconds when using mboxes.
|
David Empson <dempson> |
Mon 28 May 2007 08:40:29 AM UTC, comment #10:
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.
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. |
Atte Kojo <kojo> |
Sat 26 May 2007 01:51:17 PM UTC, comment #9: 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).
|
Frédéric Bernon <fbernon> |
Thu 24 May 2007 03:12:42 PM UTC, comment #8: About comment #6:
|
Frédéric Bernon <fbernon> |
Thu 24 May 2007 01:52:41 PM UTC, comment #7:
|
Simon Goldschmidt <goldsimon> |
Thu 24 May 2007 01:39:13 PM UTC, comment #6: Re comment #14: Speed versus footprint is usually a trade-off. But it's harder to shrink a complex implementation, than it is to speed up a small implementation. So I suggest ensuring that footprint is first, with speed only in mind, than the other way round.
|
Jonathan Larmour <jifl> |
Thu 24 May 2007 01:33:42 PM UTC, comment #5:
|
Frédéric Bernon <fbernon> |
Thu 24 May 2007 01:14:12 PM UTC, comment #4: Actually, our number, number two, and number three customer requirements are: 1. speed, you must be able to run near 100mbps, 2. processor loading; it must not use 100% of the cpu to do that, and 3. footprint, it needs to be small. We are likely going to be taking a very hard look at these three items in parallel to the R & D of the extended protocols I was talking about yesterday.
|
Paul Decker <pdecker> |
Thu 24 May 2007 01:02:24 PM UTC, comment #3: I vote for re-implementing the sockets API from scratch directly on top of the raw API using mutexes for synchronization.
|
Atte Kojo <kojo> |
Thu 24 May 2007 12:26:06 PM UTC, comment #2:
|
Simon Goldschmidt <goldsimon> |
Thu 24 May 2007 12:17:21 PM UTC, comment #1: The suggestions you make seem to be along the lines of fixing up the existing sockets API.
|
Kieran Mansley <kieranm> |
Thu 24 May 2007 12:00:11 PM UTC, original submission:
Note that this is marked as 'later'!
|
Simon Goldschmidt <goldsimon> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 3 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2007-06-11 | fbernon | Open/Closed | Open | Closed | |
2007-05-29 | fbernon | Attached File | - | Added API Layers measures.JPG, #12899 | |
2007-05-26 | fbernon | Attached File | - | Added API Layers measures.txt, #12864 |
Powered by Savane 3.13-758e.
Corresponding source code
yep