Jonathan Larmour wrote:
Packet-oriented netbufs can be used more efficiently than streams, and
you can't do things like netbuf_ref() etc. with streams.
I'm afraid that I don't quite understand this. Could you elaborate a bit
more?
As far as I understand, when running in flat memory "zero-copy" is more
of an illusion than anything else. Right now writes/sends on UDP sockets
with socket API are already blocking and don't copy any data between
pbufs (uses netbuf_ref i.e. PBUF_REF). TCP writes could very easily be
made "zero-copy" also with a non-standard option for send (like
MSG_DONTCOPY, which would then use netbuf_ref/PBUF_REF under the covers).
In any case not copying data for performance reasons is kind of a moot
point as the data must be gone through at least once when calculating
checksums. Doing a copy-on-checksum takes almost negligible performance
hit (depending on memory allocator implementation) so only real case for
not copying data at all is for very memory-constrained systems where the
user wants to avoid copying data from external ROM to RAM. And, as I
said earlier, this can be handled very easily.
PS. The main reason I'm so strongly advocating this is that I don't like
having a nonstandard API where a standard one would do. Using a socket
API that behaves just like its real counterpart is a lot easier for new
users (and us old ones also). Plus the netconn-API lacks select() which
makes single-thread servers a gazillion times easier to implement.
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
