Re: [lwip-devel] Re: [task #7040] Work on tcp_enqueue

[pweb . ing]

hi.

just some general opinion... not deep code discussion...

i wrote this email in list with object:

[lwip-devel] On PBUF was: Work on tcp_enqueue
"
.....

 there are a lot of work to do...
 - define a separate layer for pbuf managment, which can cover, using
 customization, different dma architectures.
 - break tcp write code in lwip, to allow this pbufs layer to have
 zero-copy for sending
 - guide line for write ethernetif for rx to have zero copy
 - we talked here about socket2, build without netcomm. bsd socket
 works using copy, but we can offer a way to break this rule, offering
 zero-copy option, and user-level api in new pbuf layer which works
 toghther with socket2, which hide pbufs implementation and dma
 managment behind, to the user. So, a well done lwip customization, can
 offer over an hw architecture, high performance, low ram usage, even
 the power of socket api!

 in my opinion, socket2 should have 3 layers:
 - internal structure (flags, counters,...)
 - code for socket features managment in user level api (extended
 version of bsd socket)
 - low-level functions, which works above internal structure, called
 with function pointer

 in this way a developer could have a ready-to-use socket2 above
 network driver, but can also add other socket2 family, using different
 low-level funcs (for example over serial streaming, over OS data
 streaming...) which sharebthe same code for socket managment and user
 api.... thinks "select" function over different sockets... thins that
 in embedded device, cooperation between os, networking, other hw
 streaming could became necessary, and have only one interface above -
 socket2 - could be a killer idea!

 i know... i'm talking about lwip 2.0.0, right :o) ? someone has the
 same dream or i'm the only crazy developer?
"

bye
Piero



2009/2/1, Jakob Stoklund Olesen <address@hidden>:
> "address@hidden" <address@hidden> writes:
>
>> Jakob Stoklund Olesen wrote:
>>> Sure, but UDP performance is rarely critical, and it seems wasteful to
>>> extend struct pbuf just for that.
>>
>> I wouldn't think so. If you want high throughput and can cope with
>> lost segments, UDP is the better alternative to TCP and would still
>> require high throughput!
>
> You are right, I didn't think of the multimedia protocols.
>
>> However, the goal of that patch (and its
>> discussion) was to NOT include another member in struct pbuf but to
>> solve it in a different way (which is why it is still open and not
>> finished).
>
> Right. Do you think my proposals for TCP are a detour from a unified
> solution? I think the requirements for TCP and UDP/UDPLite are different
> enough that little can be shared.
>
> I would probably make these functions:
>
> inet_chksum_pseudo_header(): inet_chksum_pseudo without payload.
> inet_chksum_memcpy(): Checksumming memcpy.
>
> They would be useful for UDP as well.
>
> For TCP, a checksum field in the pbuf is not really that useful. A
> data_csum field in tcp_seg might be, but it is not strictly necessary.
>
>
>
> _______________________________________________
> lwip-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-devel
>