|
From: | Atte Kojo |
Subject: | Re: [lwip-users] Why does sys_sem_wait_timeout exist? |
Date: | Wed, 28 Feb 2007 08:26:19 +0200 |
User-agent: | Thunderbird 1.5.0.8 (X11/20061107) |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |