| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Fri, 19 Nov 2010 13:32:57 -0800 From: Rick Jones <rick.jones2@...com> To: Tom Herbert <therbert@...gle.com> CC: Linux Netdev List <netdev@...r.kernel.org> Subject: Re: Generalizing mmap'ed sockets I suppose then one would be able to track the consumer pointer (on tx) to "know" that certain data had been ACKed by the remote? For TCP anyway - and assuming there wouldn't be a case where TCP might copy the data out of the ring and assert "completion." How would the mmap'ing interact with autotuning? Particularly in the "future case" of HW support for true zero copy on receive. Today I can be assured that data I receieve is on a "nice" boundary in my memory by virtue of the buffer pointer I pass to the recv() call, but with the "rings" (they are simply some chunk of virtually continguous data yes?) it will just be bumped up against the end of the last one - I'm wondering if that might not be a problem, especially for UDP datagrams, but even for TCP data? It is one thing to have people pad structures in the memory of a system, but telling them to pad-out the messages they send across the network to maintain alignment is rather different. How do you differentiate between a "there is data to send" and "I want to send a zero-legnth datagram for a UDP socket? I think you will have to do/overload something other than a send() call for the trigger. rick jones -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists