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

[pweb . ing]

hi

i agree with you.
we have to find a place and a way to work toghether, producing code and docs.

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?


2009/1/30, Alain M. <address@hidden>:
> I am jijacking this thread for a subject that has come along in it:
>
> PBUF
>
> I would like to suggest a place to list all different necessities
> regarding pbufs, maybe a special page in the wiki (if many devellopers
> can have write access)
>
> There are lots of different aspects, just to name a few:
> - zero copy
> - copy optimyzed: on 32 bit archs, an specially ARM and CortexM3 there a
> lot of tricks to speed up copy about 5 times!! things like word aligment
> but also multiples or 4/8 words for fast copy, etc..
> - DMA: this is very usefull and varies wildly in various archs
> - internal copy and pbuf list, as stated in this mesage about tcp_enqueue
> - etc..
>
> Maybe that if we manage to put all this toghether, a future version or
> patch could be more flexible!!
>
> first list what is needed
> second plan
> third to it, if someone volunteers, of course :)
>
> Alain
>
>
> Jakob Stoklund Olesen escreveu:
>> Follow-up Comment #8, task #7040 (project lwip):
>>
>> 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.
>>
>> I have attached a patch for tcp_enqueue that fixes the issue discussed
>> here.
>> It was not as simple as I had hoped. The tcp_enqueue function is quite
>> scary.
>> I have tested this patch, but please try to test it on different systems.
>> There are many things that can go wrong.
>
>
>
> _______________________________________________
> lwip-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-devel
>