lwIP - A Lightweight TCP/IP stack - Bugs: bug #49914, lwip_sendmsg uses PBUF_REF pbufs
You are not allowed to post comments on this tracker with your current authentication level.
bug #49914: lwip_sendmsg uses PBUF_REF pbufs
Submitter: | Dirk Ziegelmeier <dziegel> | ||
Submitted: | Thu 22 Dec 2016 08:13:42 PM UTC | ||
Category: | sockets/netconn | Severity: | 3 - Normal |
Item Group: | Change Request | Status: | Invalid |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Closed | Planned Release: | None |
lwIP version: | 2.0.0 |
Jump to the original submission
Sun 15 Jan 2017 04:16:20 PM UTC, comment #13: |
Dirk Ziegelmeier <dziegel> |
Mon 09 Jan 2017 11:11:39 PM UTC, comment #12: I'm curious to see how the Linux driver for that hardware handles the alignment. I'm somewhat familiar with Linux socket buffers and did a little digging.
|
Joel Cunningham <jcunningham> |
Sat 07 Jan 2017 07:52:35 PM UTC, comment #11: Even DMA-enabled netifs have more problems. I wrote a driver for the Synopsys Designware MAC (in Linux its called "stmmac"). It is capable of scatter-gather DMA, but has alignment requirements for the buffer (I guess resulting from burst-access boundaries). So even for this MAC, I was unable to use zero-copy TX because the RAM PBUFs did not satisfy the alignment requirements.
|
Dirk Ziegelmeier <dziegel> |
Tue 27 Dec 2016 08:44:14 PM UTC, comment #10: The extra expense is not only for sockets: DMA enabled netifs must handle PBUF_REF from any source correctly, so why not for sockets, too? |
Simon Goldschmidt <goldsimon> |
Tue 27 Dec 2016 08:36:57 PM UTC, comment #9: Dirk,
|
Joel Cunningham <jcunningham> |
Fri 23 Dec 2016 09:02:08 PM UTC, comment #8: Zero-copy depends on the application:
|
Dirk Ziegelmeier <dziegel> |
Fri 23 Dec 2016 04:32:21 PM UTC, comment #7: Hm yes, I was suggesting a whole-chain copy because of Simon's earlier point here: messing with next-pointers of an in-use chain is not necessarily risk-free - in fact, I don't think it can be done safely for the header=RAM,data=REF case without making assumptions about the way that, say, udp_send() is used. So I'd say optimizing that part is probably not worth it, given the likely small gain it would yield anyway. Of course the nice thing about hiding this stuff behind an API is that it's easy to change later anyway.. :) |
David van Moolenbroek <dcvmoole> |
Fri 23 Dec 2016 03:53:24 PM UTC, comment #6: David,
|
Joel Cunningham <jcunningham> |
Fri 23 Dec 2016 11:16:15 AM UTC, comment #5: My 2c here, which probably just rehashes much of what's being discussed elsewhere already, but with a concrete proposal..
|
David van Moolenbroek <dcvmoole> |
Fri 23 Dec 2016 09:00:19 AM UTC, comment #4: OK, I reverted it for now. This seems to need some more discussion.
|
Dirk Ziegelmeier <dziegel> |
Fri 23 Dec 2016 07:54:39 AM UTC, comment #3: Good point on the PBUF_RAM which is normally in a chain as a header. I think for writing a netif that did asynchronous output, it would be a good practice to copy the entire chain and not just any PBUF_REF pbufs. We've discussed this before, but a TCP segment is still referenced after output. During retransmission, the TCP header (contained in a PBUF_RAM) is modified without checking the reference count. Given this behavior, it seems unsafe for a netif to hold a reference to a pbuf after the output function has completed. Maybe any netif developers that have written asynchronous output can share their approach.
|
Joel Cunningham <jcunningham> |
Fri 23 Dec 2016 07:01:10 AM UTC, comment #2: I can understand your position Joel. And I think we should support zero copy in this case.
|
Simon Goldschmidt <goldsimon> |
Fri 23 Dec 2016 05:20:31 AM UTC, comment #1: Dirk,
|
Joel Cunningham <jcunningham> |
Thu 22 Dec 2016 08:13:42 PM UTC, original submission:
... and thus does not create a copy of the data to be sent in RAW/UDP case.
|
Dirk Ziegelmeier <dziegel> |
No files currently attached
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 7 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2017-01-15 | dziegel | Status | None | Invalid | |
Open/Closed | Open | Closed | |||
2016-12-23 | dziegel | Item Group | Faulty Behaviour | Change Request | |
Status | Fixed | None | |||
Open/Closed | Closed | Open | |||
2016-12-22 | dziegel | Status | None | Fixed | |
Open/Closed | Open | Closed |
Powered by Savane 3.13-d3ae.
Corresponding source code
I think Simon's ideas about rewriting the PBUF allocation is a good solution for this. There has to be some way to delegate the PBUF allocation to the application, there may be too many different requirements to implement them all in lwip, especially the alignment stuff I described.