lwIP - A Lightweight TCP/IP stack - Tasks: task #6735, Provide new pbuf type:...
You are not allowed to post comments on this tracker with your current authentication level.
task #6735: Provide new pbuf type: PBUF_RAM_NOCOPY
Submitter: | Jonathan Larmour <jifl> | ||
Submitted: | Tue 10 Apr 2007 02:24:22 PM UTC | ||
Category: | None | Should Start On: | Mon 09 Apr 2007 11:00:00 PM UTC |
Should be Finished on: | Sat 09 Jun 2007 11:00:00 PM UTC | Priority: | 7 - High |
Status: | Cancelled | Privacy: | Public |
Assigned to: | jifl | Percent Complete: | 50% |
Open/Closed: | Closed | Planned Release: | 1.4.0 |
Effort: | 0.00 |
Jump to the original submission
Thu 27 Mar 2008 10:25:22 PM UTC, comment #34: |
Jonathan Larmour <jifl> |
Tue 25 Mar 2008 01:11:27 PM UTC, comment #33: Now that 1.3.0 is out the door we should revisit this.
|
Kieran Mansley <kieranm> |
Fri 19 Oct 2007 08:27:07 PM UTC, comment #32: EVS Hardware Dpt wrote:
|
Jonathan Larmour <jifl> |
Fri 19 Oct 2007 01:43:51 PM UTC, comment #31: After reading the whole discussion my conclusion is that you want to be sure that each time you call an output function (tcp_write, udp_send,...) the buffer is free for re-use ?
|
EVS Hardware Dpt <vse> |
Sun 12 Aug 2007 04:36:15 PM UTC, comment #30: In the patch attached here, I included a macro PBUF_NEEDS_COPY(_p). |
Jonathan Larmour <jifl> |
Sun 12 Aug 2007 02:54:18 PM UTC, comment #29: Then maybe we should provide a function that checks whether a pbuf to be enqueued must be copied or not, like 'q = pbuf_to_enqueue(p)', so that this knowledge is wrapped in another function, not in every driver. |
Simon Goldschmidt <goldsimon> |
Sun 12 Aug 2007 01:30:30 PM UTC, comment #28:
|
Jonathan Larmour <jifl> |
Sat 11 Aug 2007 09:06:34 AM UTC, comment #27:
|
Simon Goldschmidt <goldsimon> |
Fri 10 Aug 2007 08:53:32 PM UTC, comment #26:
|
Jared Grubb <jgrubb> |
Fri 10 Aug 2007 07:23:01 PM UTC, comment #25:
|
Jonathan Larmour <jifl> |
Fri 10 Aug 2007 06:48:36 PM UTC, comment #24:
I personally think the driver should never copy. The stack should take care of all of that when it is necessary. |
Jared Grubb <jgrubb> |
Fri 10 Aug 2007 03:35:11 PM UTC, comment #23:
|
Jonathan Larmour <jifl> |
Fri 10 Aug 2007 03:20:03 PM UTC, comment #22:
|
Jared Grubb <jgrubb> |
Fri 10 Aug 2007 02:10:19 PM UTC, comment #21:
|
Jonathan Larmour <jifl> |
Fri 10 Aug 2007 08:21:06 AM UTC, comment #20: Jonathan,
|
Simon Goldschmidt <goldsimon> |
Thu 09 Aug 2007 06:26:09 PM UTC, comment #19:
|
Jared Grubb <jgrubb> |
Thu 09 Aug 2007 04:16:26 PM UTC, comment #18:
|
Jonathan Larmour <jifl> |
Thu 09 Aug 2007 03:01:08 PM UTC, comment #17: So if implementing PBUF_RAM_NOCOPY (and using it in TCP and all other stack-internal uses of PBUF_RAM), this would still leave us with the fact that the present zero-copy sending for UDP sockets would not work any more! At least for most hardware (as DMA MACs are rather widely used).
|
Simon Goldschmidt <goldsimon> |
Wed 01 Aug 2007 02:26:00 PM UTC, comment #16: Kieran Mansley wrote:
|
Jonathan Larmour <jifl> |
Wed 01 Aug 2007 08:03:01 AM UTC, comment #15: In my opinion, if the application was going to use the buffers in that way (i.e. never modify the contents, just free it after sending) they could just use the PBUF_ROM type (or the suggested new PBUF_RAM_NOCOPY if the stack should do the free) and the stack would have the guarantees it needs. We should assume that if they've used PBUF_REF, they have done so for a reason. The current API allows the application to choose both ways, so I'd rather not restrict it if we don't have to.
|
Kieran Mansley <kieranm> |
Tue 31 Jul 2007 06:52:36 PM UTC, comment #14:
|
Jared Grubb <jgrubb> |
Tue 31 Jul 2007 06:14:40 PM UTC, comment #13: In comment #11, Jared Grubb wrote:
|
Jonathan Larmour <jifl> |
Tue 31 Jul 2007 05:41:53 PM UTC, comment #12:
|
Jared Grubb <jgrubb> |
Tue 31 Jul 2007 05:21:02 PM UTC, comment #11:
|
Jared Grubb <jgrubb> |
Tue 31 Jul 2007 01:19:04 AM UTC, comment #10: Re Frederic's comment #9:
|
Jonathan Larmour <jifl> |
Mon 30 Jul 2007 11:24:07 PM UTC, comment #9:
|
Frédéric Bernon <fbernon> |
Mon 30 Jul 2007 09:59:35 PM UTC, comment #8: (background: relative newcomer to lwIP)
|
Jared Grubb <jgrubb> |
Mon 30 Jul 2007 07:23:23 PM UTC, comment #7: Hopefully the patch in the attachment is straightforward. It's a lot smaller than I thought it would be.
|
Jonathan Larmour <jifl> |
Tue 03 Jul 2007 07:11:53 AM UTC, comment #6: Wouldn't it be good to add an assertion into sockets.c:lwip_sendto() at the point where the pbuf is freed that there is no other reference to it? (i.e. p->ref == 1) If ref is > 1, the MAC still holds a reference (because the packet is still queued) and that might lead to wrong data being sent. If such an assert triggers, the user must switch to use PBUF_RAM(_NOCOPY?) instead. |
Simon Goldschmidt <goldsimon> |
Sat 09 Jun 2007 11:04:31 AM UTC, comment #5: Just so that we better find what we discussed about:
|
Simon Goldschmidt <goldsimon> |
Tue 24 Apr 2007 06:04:19 PM UTC, comment #4:
|
Simon Goldschmidt <goldsimon> |
Tue 24 Apr 2007 01:58:49 PM UTC, comment #3: Re comment #1: yep there's a lot of good things that become possible once we have a way to know what we need to do with a pbuf.
|
Jonathan Larmour <jifl> |
Mon 23 Apr 2007 10:35:35 AM UTC, comment #2: Also, it would be usefule to have a function like tcp_write() that accepts pre-filled pbufs. That way, an application can generate packet directly into a pbuf. For protocols that send dynamic data, this could completely eliminate copying. (together with a flag like 'copy' that indicates if the data should be copied or put on the segment-queue directly (the pbuf may not be changed by the application thereafter)).
|
Simon Goldschmidt <goldsimon> |
Mon 23 Apr 2007 07:28:48 AM UTC, comment #1: Just a little comment so that we don't forget it:
|
Simon Goldschmidt <goldsimon> |
Tue 10 Apr 2007 02:24:22 PM UTC, original submission:
As discussed in thread "Packet queues" on ecos-devel around 5th April.
|
Jonathan Larmour <jifl> |
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 8 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2008-03-27 | jifl | Status | None | Cancelled | |
Open/Closed | Open | Closed | |||
2008-03-25 | kieranm | Planned Release | None | 1.4.0 | |
2008-03-25 | kieranm | Priority | 3 - Low | 7 - High | |
2007-08-29 | kieranm | Priority | 5 - Normal | 3 - Low | |
2007-07-31 | jifl | Carbon-Copy | - | Added kieranm | |
2007-07-30 | jifl | Attached File | - | Added lwip.pbuf.nocopy.patch.txt, #13528 | |
Percent Complete | 0% | 50% |
Powered by Savane 3.13-f8d8.
Corresponding source code
Unfortunately I will be up to my ears for the next 3 weeks or so, and even then, I need to update my own port to 1.3.0 first. If someone else wants to run with this feel free, however given Kieran's comment, really this particular task is now invalid. If pbufs can't be reused, we no longer need a separate PBUF_RAM_NOCOPY pbuf type.
But there's still a lot to do to support zero-copy transmits and receives. For receives, there are usually requirements for things such as using specific memory regions (PCI windows, or dedicated DMA regions, or on-chip RAM, etc.), as well as alignment and buffer size constraints. One port I've already done with my own zero-copy rx mods is to AT91SAM7X which uses fixed 128-byte buffers, thus requiring fixed 128-byte pool pbufs. Fortunately I could still keep the existing pool structure, but that won't be true on other systems - it will need to be possible to separate the struct pbuf, from the following pool memory itself. The simplest way I can think of is to keep the struct pbuf and the pbuf memory itself in parallel arrays. So if you have the pbuf start, then since the pbufs are of constant size and you know the base, you can easily calculate the index of this pbuf, and therefore the index of the corresponding struct pbuf.
Another requirement is that drivers need to be informed when more of that pool memory becomes available, as often the hardware has its own circular buffer lists, and these will need to be marked as available again, once a pool pbuf has been freed.
So far I only have a solution for one ethernet driver at a time. Implementing this for multiple ones (efficiently) is more tricky since of course it's possible for drivers to have different requirements. The easiest solution is probably to say they can't do it then.
Anyway, I'm closing this task as invalid, and I'll open a new task for the above.