patchlwIP - A Lightweight TCP/IP stack - Patches: patch #7454, add support for pbuf as an...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

patch #7454: add support for pbuf as an argument to tcp_write()

Submitter:  Matt Dittrich <mdittrich>
Submitted:  Mon 31 Jan 2011 06:32:18 AM UTC
   
 
Category:  TCP Priority:  5 - Normal
Status:  Wont Do Privacy:  Public
Assigned to:  goldsimon Open/Closed:  Closed
Planned Release:  None

Fri 09 Dec 2016 11:28:05 AM UTC, comment #3: 

By now, I don't think the way this patch solves it is good. We need a type-safe (new) function to pass pbufs to tcp (i.e. tcp_write_pbuf() or slt.).

After all, we have task #10273 for this issue.

Simon Goldschmidt <goldsimon>
Group administrator
Sat 29 Oct 2011 08:23:46 PM UTC, comment #2: 

I don't think splitting pbufs would make sense. And mem_slit() wouldn't even work, as you need control structures between every heap element (the 'next' pointer, at least). I think an application should simply allocate a pbuf in the correct length (i.e. a pbuf >= MSS should be rejected and there should be a way to get the amount of free space in the last unsent segment to create pbufs of appropriate size).

I still think this would be an interesting feature for a zero-copy httpd.

BTW: also see task #10273.

Simon Goldschmidt <goldsimon>
Group administrator
Wed 02 Feb 2011 07:51:43 PM UTC, comment #1: 

It seems that these patches are a bit premature, tcp_write() doesn't correctly handle pbuf chains longer than pcb->mss.  I think splitting the large pbuf into mss sized chunks would require new pbuf_split() and mem_split() that do much of what pbuf_realloc() and mem_trim() do now, but without discarding/freeing their remainders.  New nodes in the respective lists would be inserted to maintain the remainder.  I think the split lengths would also have to be restricted to respect alignment.  pbuf_split() would fail when the "split point" of the chain lies within a PBUF_POOL.

Its not a trivial amount of code to get working (FYI: pbuf_realloc() and mem_trim() occupy ~344 bytes on my -O2 Cortex-M3). Would this code be useful in other parts of the stack (I am not familiar with the socket implementation)?

I had not encountered this in my original testing because I was  using it for CGI response generation in httpserver_raw... the TCP_WRITE_FLAG_PBUF output was always less than mss and at the beginning of a segment.  So as they stand, the patches have limited usefulness.

Thanks,
MD

Matt Dittrich <mdittrich>
Mon 31 Jan 2011 06:32:18 AM UTC, original submission:  

The attached tcp_write_pbuf1/2.patch extend tcp_write() to accept a pbuf chain as the data source.  This allows the application to allocate memory and have the stack manage freeing the pbufs, possibly saving the memcpy() that TCP_WRITE_FLAG_COPY uses. I only tested with PBUF_RAM, with LWIP_CHECKSUM_ON_COPY off.

The attached pbuf_memcpy1/2.patch add pbuf_memcpy() and apply on top of the tcp_write() patches.  pbuf_memcpy() "fills" a pbuf chain from a user buffer like pbuf_take(), but maintains state (position in the chain) between calls so it can be called multiple times on the same chain. A call to pbuf_memcpy_cleanup() is required to fixup the lengths before a call to tcp_write().  pbuf_memcpy() could replace pbuf_take() without much execution time penalty.

I found that the pbuf_mempy()'d data gets corrupted when sent if a pbuf in the chain has an uneven length... might be my MAC driver.

MD

Matt Dittrich <mdittrich>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #22562:  tcp_write_pbuf1.patch added by mdittrich (3KiB - application/octet-stream)
file #22563:  pbuf_memcpy1.patch added by mdittrich (4KiB - application/octet-stream)
file #22564:  tcp_write_pbuf2.patch added by mdittrich (473B - application/octet-stream)
file #22565:  pbuf_memcpy2.patch added by mdittrich (889B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by mdittrich (Submitted the item)
  •  

    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
    2016-12-09 goldsimon StatusNone Wont Do
        Assigned toNone goldsimon
        Open/ClosedOpen Closed
    2013-01-15 goldsimon CategoryNone TCP
    2011-01-31 mdittrich Attached File- Added tcp_write_pbuf1.patch, #22562
        Attached File- Added pbuf_memcpy1.patch, #22563
        Attached File- Added tcp_write_pbuf2.patch, #22564
        Attached File- Added pbuf_memcpy2.patch, #22565

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code