lwIP - A Lightweight TCP/IP stack - Tasks: task #6849, Test how checksum on copy could be...
You are not allowed to post comments on this tracker with your current authentication level.
task #6849: Test how checksum on copy could be integrated into the stack
Submitter: | Simon Goldschmidt <goldsimon> | ||
Submitted: | Fri 04 May 2007 06:40:48 AM UTC | ||
Category: | None | Should Start On: | Fri 04 May 2007 12:00:00 AM UTC |
Should be Finished on: | Fri 04 May 2007 12:00:00 AM UTC | Priority: | 5 - Normal |
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
Sun 16 May 2010 01:17:15 PM UTC, comment #35: |
Simon Goldschmidt <goldsimon> |
Fri 30 Apr 2010 08:41:02 PM UTC, comment #34: Oh, and we might want to use the new checksum-on-copy from the socket API when sending UDP data... |
Simon Goldschmidt <goldsimon> |
Fri 30 Apr 2010 08:40:08 PM UTC, comment #33: Added udp_send(_to/_if) functions that take a precalculated checksum, added pbuf_fill_chksum() to copy data into a pbuf and at the same time calculating the checksum for that data.
|
Simon Goldschmidt <goldsimon> |
Fri 26 Mar 2010 09:20:00 AM UTC, comment #32:
|
Simon Goldschmidt <goldsimon> |
Thu 25 Mar 2010 09:20:22 PM UTC, comment #31: I think on RX, should we assume that there is full checksum offloading? If the MAC is going to do this, I would expect it to do everything (as it does on the PC, or seems to). If the Ethernet driver is going to receive the packet and then do the hardware checksum, it will have to do some parsing to decide what to do and fill in the checksum in the correct places. If it's to be done any higher up than that, then inet_chksum can use the hardware to checksum a pbuf (or pbuf chain) just as easily. I guess the question is, where is the copy we're checksumming on copy? The callbacks provide a pointer to the payload and I used to hardware copy to concatenate the packets or I've never had to copy incoming data - just look at it and do something locally with it. It's been outgoing where I could do the checksum as the data was being streamed.
|
Bill Auerbach <billauerbach> |
Thu 25 Mar 2010 09:05:14 PM UTC, comment #30: Well, OK, but how is that going to work for RX? As far as I can remember, pbuf_header works on all pbuf types when hiding headers (not when unhiding them, i.e. expanding to the front, which is what you took advantage of).
|
Simon Goldschmidt <goldsimon> |
Thu 25 Mar 2010 06:47:38 PM UTC, comment #29: I meant to reply but it got away from me.
|
Bill Auerbach <billauerbach> |
Thu 25 Mar 2010 06:36:43 PM UTC, comment #28: No comments about my last question? If not, I'll close patch #6253 as "won't do", since I don't see how it would work (given the description in my last comment). |
Simon Goldschmidt <goldsimon> |
Tue 16 Mar 2010 03:11:31 PM UTC, comment #27: I meant something different: I didn't need an u32_t but only an u16_t for the checksum (over the complete payload) and a bit in p->flags. So far it's not much different from what you did.
|
Simon Goldschmidt <goldsimon> |
Tue 16 Mar 2010 12:54:36 PM UTC, comment #26: I used a u32_t in the pbuf so I could use a special value to say "Need checksum calcualted". If not that value, I skipped the inet_chksum call and simply added in this field. I made the assumption in my method that a pbuf had a checksum only for it's payload, but chained pbufs each with a checksum was allowed.
|
Bill Auerbach <billauerbach> |
Tue 16 Mar 2010 05:58:30 AM UTC, comment #25: The problem I saw so far (and which hasn't been solve in patch #6253) is that it's not clear to me how one 'u16_t chksum' could be enough: at the point of allocating, the checksum would be over the data (payload + len), but what part of the pbuf would be covered by the checksum after changing the payload pointer using pbuf_header()? We would then either need another u16_t 'chksum_offset' (which would have to be adapted in pbuf_header), or the inet_checksum_* functions would have to know the offset by knowing the protocol type and its length (which is hard for TCP options). |
Simon Goldschmidt <goldsimon> |
Mon 15 Mar 2010 07:20:10 PM UTC, comment #24: My opinion is that if the value stored is the checksum for just the data in the pbuf then it's fine to keep it in the pbuf. If the value stored is the checksum for the whole packet, it should be kept in whatever structure keeps the metadata for the whole packet (e.g. tcp_seg). If it's computed for each pbuf separately that makes some things easier (e.g. resegmenting tcp_writes) with only a small cost of summing the per-buffer values together when we need to work out the whole packet. I do want to make sure that we don't make the pbuf structure any larger though, and Simon's suggestion should do that. |
Kieran Mansley <kieranm> |
Mon 15 Mar 2010 06:16:44 PM UTC, comment #23:
|
Bill Auerbach <billauerbach> |
Mon 15 Mar 2010 05:48:43 PM UTC, comment #22: In my case, I had the ability for the hardware to send me the payload part of the packet with its checksum. So the stack does the IP header and its checksum, and the payload was passed in with the checksum. When the segment was created with the checksum, I filled it in (in the pbuf but just as easily could have been in the tcp_seg). I was sending full MSS-sized data so multiple segments didn't apply (which is why it was a trivial change for me). For UDP, I put the checksum in the pbuf and the code that checksums pbufs (and chains) just added in the checksum supplied (if supplied) or calculated it otherwise. Note the even/odd detail fell out without any added code. So for both UDP and TCP to work the same was the reason why I mentioned the checksum belongs in the pbuf. There are no tcp_segs with UDP. So maybe it doesn't belong there from a layer or design standpoint, but it looked like a better fit for TCP and UDP to work alike. (No Kieran, I'm not trying to change your mind :-) ).
|
Bill Auerbach <billauerbach> |
Mon 15 Mar 2010 04:48:28 PM UTC, comment #21: I think we are mixing 2 things here:
|
Simon Goldschmidt <goldsimon> |
Mon 15 Mar 2010 04:25:11 PM UTC, comment #20: I hope it would only grow with this option enabled. |
Bill Auerbach <billauerbach> |
Mon 15 Mar 2010 04:22:55 PM UTC, comment #19: Oh, and in patch #6253, the main point was that struct pbuf shouldn't grow larger if we can avoid it: there are targets limited in RAM that benefit from the per-segment storage, even when mixing PBUF_RAM with PBUF_REF (tcp copy/nocopy). |
Simon Goldschmidt <goldsimon> |
Mon 15 Mar 2010 04:18:54 PM UTC, comment #18: I didn't argue at any time that it wouldn't work with the checksum in the pbuf, but I also think that the checksum logically belongs to the segment.
|
Simon Goldschmidt <goldsimon> |
Mon 15 Mar 2010 12:47:58 PM UTC, comment #17: I disagree: logically a checksum should belong to the segment not the buffer (of which there may be many). |
Kieran Mansley <kieranm> |
Mon 15 Mar 2010 12:45:31 PM UTC, comment #16:
|
Bill Auerbach <billauerbach> |
Sun 14 Mar 2010 12:30:13 PM UTC, comment #15: When implementing udp_send_chksum, to prevent duplicating code, we'd have to separate calculating the checksum of (pbuf-)data from calculating the header checksum. Then, udp_send would first calculate the checksum and then go the same path as udp_send_checksum.
|
Simon Goldschmidt <goldsimon> |
Sun 14 Mar 2010 12:08:59 PM UTC, comment #14: I finally found the time to work on this. For now, I've added the code as an option (LWIP_CHECKSUM_ON_COPY):
|
Simon Goldschmidt <goldsimon> |
Mon 11 May 2009 07:30:15 PM UTC, comment #13: Yes, it can be done with lwIP not to checksum changing those #defines but it's far from ideal because the driver has to parse the outgoing packet to decide what to checksum. IMO this is good for hardware which is parsing packets and checksumming on the fly. Those who want to checksum with hardware but not with packet parsing need an alternative. What I want to do doesn't get the headers checksummed so my idea of wanting to do just the TCP payload isn't complete, but it checksums a majority of the data passing through which I can do in hardware. |
Bill Auerbach <billauerbach> |
Mon 11 May 2009 04:09:09 PM UTC, comment #12: 1) is done by telling lwIP to not care for creating/checking a specific checksum (UDP, TCP, ICMP, IP). There are already defines for that.
|
Simon Goldschmidt <goldsimon> |
Mon 11 May 2009 02:52:59 PM UTC, comment #11: I wanted to add a point. There are 2 checksum options to consider:
|
Bill Auerbach <billauerbach> |
Sun 10 May 2009 05:37:18 PM UTC, comment #10: Sorry, forgot something:
|
Simon Goldschmidt <goldsimon> |
Sun 10 May 2009 05:36:05 PM UTC, comment #9: [Referring a little bit to the discussion in patch #6253: Added csum to struct pbuf.]
|
Simon Goldschmidt <goldsimon> |
Thu 07 May 2009 05:47:15 AM UTC, comment #8:
|
Simon Goldschmidt <goldsimon> |
Wed 06 May 2009 08:58:14 PM UTC, comment #7: I can help out on this task. We can have our hardware stream data and generate checksums while copying the data. My idea was to have it drop 0 to pcb->mss bytes into memory with a u16_t word following, which is the checksum of the packet. If a tcp_enqueue_with_checksum existed which took up to pcb->mss and the checksum for the data being sent, then a packet could be queued inserting the checksum in the header.
|
Bill Auerbach <billauerbach> |
Tue 25 Mar 2008 09:11:51 PM UTC, comment #6: Still at it. Although testing this is a little tricky: the Win32-port didn't improve much but this might be due to the large caches of the PCs used to test... I'll test again on an Altera NIOS-II platform, when I find the time.
|
Simon Goldschmidt <goldsimon> |
Tue 25 Mar 2008 01:13:55 PM UTC, comment #5: Simon - does this still interest you?
|
Kieran Mansley <kieranm> |
Fri 04 May 2007 11:05:14 AM UTC, comment #4:
|
Simon Goldschmidt <goldsimon> |
Fri 04 May 2007 11:02:23 AM UTC, comment #3:
|
Simon Goldschmidt <goldsimon> |
Fri 04 May 2007 10:59:20 AM UTC, comment #2: Actually thinking about the TCP case a bit more, I guess a seg could store some extra intermediate state to allow the checksum to be computed on an ongoing basis as things are added - 32-bit accumulator, and whether there was an odd byte yet to be added. tcp_output could then generate the checksum from that.
|
Jonathan Larmour <jifl> |
Fri 04 May 2007 10:23:48 AM UTC, comment #1: For UDP pbufs that need to be copied this is sensible, but for TCP it's more difficult - what you enqueue doesn't necessarily correspond to what gets sent - each time you enqueue something you may be adding it to an existing segment, and you don't want to have to recalculate the checksum each time something is queued.
|
Jonathan Larmour <jifl> |
Fri 04 May 2007 06:40:48 AM UTC, original submission:
Creating the checksum for UDP/TCP pbufs could be done when copying them (e.g. in tcp_enqueue() if copy==1), which could significantly increase send performance.
|
Simon Goldschmidt <goldsimon> |
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 8 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2010-05-16 | goldsimon | Open/Closed | Open | Closed | |
2010-05-16 | goldsimon | Status | In Progress | Done | |
Percent Complete | 70% | 100% | |||
2010-04-30 | goldsimon | Percent Complete | 40% | 70% | |
2010-03-14 | goldsimon | Status | None | In Progress | |
Percent Complete | 0% | 40% | |||
2008-03-25 | kieranm | Planned Release | None | 1.4.0 | |
2008-03-25 | kieranm | Priority | 1 - Later | 5 - Normal |
Powered by Savane 3.13-d3ae.
Corresponding source code
Done.
We have task #10273 for that.