lwIP - A Lightweight TCP/IP stack - Tasks: task #7040, Work on tcp_enqueue
You are not allowed to post comments on this tracker with your current authentication level.
task #7040: Work on tcp_enqueue
Submitter: | Simon Goldschmidt <goldsimon> | ||
Submitted: | Tue 26 Jun 2007 07:56:13 PM UTC | ||
Category: | None | Should Start On: | Tue 26 Jun 2007 12:00:00 AM UTC |
Should be Finished on: | Tue 26 Jun 2007 12:00:00 AM UTC | Priority: | 1 - Later |
Status: | Done | Privacy: | Public |
Assigned to: | goldsimon | Percent Complete: | 100% |
Open/Closed: | Closed | Planned Release: | 1.4.0 |
Effort: | 0.00 |
Jump to the original submission
Tue 04 May 2010 07:39:58 PM UTC, comment #27: |
Simon Goldschmidt <goldsimon> |
Thu 11 Mar 2010 09:30:16 PM UTC, comment #26: Just found a bug in the committed patch: mixing COPY with NOCOPY writes leads to copying NOCOPY writes, too (which doesn't corrupt anything but leads to unnecessary copying). |
Simon Goldschmidt <goldsimon> |
Fri 05 Mar 2010 12:27:11 PM UTC, comment #25:
|
Simon Goldschmidt <goldsimon> |
Fri 05 Mar 2010 11:47:10 AM UTC, comment #24: Thanks for taking the time to get this change in.
|
Kieran Mansley <kieranm> |
Fri 05 Mar 2010 11:39:09 AM UTC, comment #23: I just noticed we might want to trim (pbuf_realloc) the oversized pbufs once they are sent (i.e. moved from unsent to unacked) to free unused memory.
|
Simon Goldschmidt <goldsimon> |
Fri 05 Mar 2010 11:15:23 AM UTC, comment #22: I finally found the time to integrate Jakob's patches into CVS. There have been some changes to the CVS tcp code though since creating the patch - I hope I didn't break it while adapting to CVS HEAD.
|
Simon Goldschmidt <goldsimon> |
Sun 19 Apr 2009 12:35:35 PM UTC, comment #21: Reminder from bug #25094: at least for no-copy data, TCP header should not be allocated until we know whether we enqueue the data in a previous segment, but I think that's covered by Jakob's patches. |
Simon Goldschmidt <goldsimon> |
Fri 03 Apr 2009 11:07:53 AM UTC, comment #20: There have been some changes to tcp_enqueue recently that probably mean these patches don't apply cleanly, and that splitting the tcp_enqueue function into two (one for options and one for data) is no longer viable as tcp_write() may want to do both. However, there is still room for cleaning up tcp_enqueue() further (e.g. by sorting out the coalescing of segments, and abstracting some of the code out into separate smaller functions).
|
Kieran Mansley <kieranm> |
Fri 13 Feb 2009 05:16:51 PM UTC, comment #19: There's a typo in tcp-enqueue-split: "SYN for FIN" should be "SYN or FIN". |
Charles Landau <clandau> |
Fri 06 Feb 2009 09:55:05 AM UTC, comment #18: Ok, attached patch tcp-oversize-smaller reduces the code size a bit when applied on top of tcp-oversize.
|
Jakob Stoklund Olesen <stoklund> |
Fri 06 Feb 2009 08:35:30 AM UTC, comment #17: Here are some code size numbers for tcp_out.c (Blackfin):
|
Jakob Stoklund Olesen <stoklund> |
Thu 05 Feb 2009 09:00:54 PM UTC, comment #16: Cool new features! But the patch is rather big, I'll try to test it on the weekend.
|
Simon Goldschmidt <goldsimon> |
Wed 04 Feb 2009 11:47:44 AM UTC, comment #15: Attached patch tcp-oversize applies on top of tcp-enqueue-split. Please disregard the earlier tcp-enqueue-concat.
|
Jakob Stoklund Olesen <stoklund> |
Tue 03 Feb 2009 09:28:33 AM UTC, comment #14: OK, second attempt: The attached patch tcp-enqueue-split splits tcp_enqueue into two separate functions for data and options.
|
Jakob Stoklund Olesen <stoklund> |
Tue 03 Feb 2009 09:18:14 AM UTC, comment #13: I can confirm that by sending
|
Iordan Neshev <iordan_neshev> |
Mon 02 Feb 2009 06:12:57 PM UTC, comment #12:
|
Bill Auerbach <billauerbach> |
Sat 31 Jan 2009 01:35:09 AM UTC, comment #11: Re comment #8: I think that this is leaning even further towards the argument of shaking up the raw TCP API by allowing data to be written as pbufs rather than char * + lengths.
|
Jonathan Larmour <jifl> |
Fri 30 Jan 2009 11:26:24 PM UTC, comment #10: Bill, thanks for testing the patch!
|
Jakob Stoklund Olesen <stoklund> |
Fri 30 Jan 2009 10:19:07 PM UTC, comment #9: I can confirm that this works with the same test I've been using when I first noticed the problem.
|
Bill Auerbach <billauerbach> |
Fri 30 Jan 2009 09:39:28 PM UTC, comment #8: First of all: I am sorry for posting comments directly to the lwip-devel list. For any new listeners out there, there is some discussion about this task in the January 2009 archives of lwip-devel.
|
Jakob Stoklund Olesen <stoklund> |
Wed 28 Jan 2009 10:34:47 PM UTC, comment #7: Can we revisit this? I don't think this has to do with Nagle. Or it also occurs without Nagle. On large transfers (RAW_API) I see it not send a full payload about 1 in 40 packets. True, this isn't a huge problem. I would expect if sending e.g. 300kB that all but the last packet would have a full payload.
|
Bill Auerbach <billauerbach> |
Thu 28 Jun 2007 11:08:28 AM UTC, comment #6: OK, I wait until nagle is fixed and take a look at it again. I still would love to fix this, but only if the fix isn't much bigger or slower than the existing solution! |
Simon Goldschmidt <goldsimon> |
Thu 28 Jun 2007 10:54:01 AM UTC, comment #5: Nagle should indeed be solving that problem, and I suggest we fix that rather than the segmentation in the queue. |
Kieran Mansley <kieranm> |
Thu 28 Jun 2007 07:16:13 AM UTC, comment #4: re comment #3:
|
Simon Goldschmidt <goldsimon> |
Wed 27 Jun 2007 05:13:22 PM UTC, comment #3: Not? If you call tcp_write many times for small chunks instead of one time for a big chunk, you will get every chunk in a single segment. Now that's what I call inefficient!
|
Simon Goldschmidt <goldsimon> |
Wed 27 Jun 2007 03:51:01 PM UTC, comment #2: I'd suggest this is not worth worrying about. The consequences are very minor.
|
Kieran Mansley <kieranm> |
Wed 27 Jun 2007 03:42:19 PM UTC, comment #1: OK, some more details: When sending much data very fast (so fast that tcp_pcb->snd_buf gets empty), an incomplete segment (smaller than pcb->mss) can be queued (and will, in most cases).
|
Simon Goldschmidt <goldsimon> |
Tue 26 Jun 2007 07:56:13 PM UTC, original submission:
If the last segment on pcb->unsent is < pcb->mss, it could hold additional data. Instead, tcp_enqueue only fills it with additional data if all the data passed to it fit in that segment.
|
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 10 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2010-05-04 | goldsimon | Status | Ready For Test | Done | |
Open/Closed | Open | Closed | |||
2010-03-05 | goldsimon | Status | None | Ready For Test | |
Percent Complete | 0% | 100% | |||
Assigned to | None | goldsimon | |||
2009-04-03 | kieranm | Planned Release | None | 1.4.0 | |
2009-02-06 | stoklund | Attached File | - | Added tcp-oversize-smaller, #17413 | |
2009-02-04 | stoklund | Attached File | - | Added tcp-oversize, #17402 | |
2009-02-03 | stoklund | Attached File | - | Added tcp-enqueue-split, #17393 | |
2009-01-30 | stoklund | Attached File | - | Added tcp-enqueue-concat, #17364 |
Powered by Savane 3.13-02a9.
Corresponding source code
Setting to 'done' as there haven't been any bug reports since setting to 'ready for test'.