Re: svn commit: r241931 - in head/sys: conf kern
On Tue, Oct 23, 2012 at 02:19:45PM +, Andre Oppermann wrote: A Author: andre A Date: Tue Oct 23 14:19:44 2012 A New Revision: 241931 A URL: http://svn.freebsd.org/changeset/base/241931 A A Log: A Replace the ill-named ZERO_COPY_SOCKET kernel option with two A more appropriate named kernel options for the very distinct A send and receive path. A A options SOCKET_SEND_COW enables VM page copy-on-write based A sending of data on an outbound socket. A A NB: The COW based send mechanism is not safe and may result A in kernel crashes. A A options SOCKET_RECV_PFLIP enables VM kernel/userspace page A flipping for special disposable pages attached as external A storage to mbufs. A A Only the naming of the kernel options is changed and their A corresponding #ifdef sections are adjusted. No functionality A is added or removed. A A Discussed with:alc (mechanism and limitations of send side COW) Users may call this a pointless POLA violation. IMO, the old kernel option that we had for years, more than a decade, should remain and just imply two new kernel options. -- Totus tuus, Glebius. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r241931 - in head/sys: conf kern
On 23.10.2012 16:42, Gleb Smirnoff wrote: On Tue, Oct 23, 2012 at 02:19:45PM +, Andre Oppermann wrote: A Author: andre A Date: Tue Oct 23 14:19:44 2012 A New Revision: 241931 A URL: http://svn.freebsd.org/changeset/base/241931 A A Log: A Replace the ill-named ZERO_COPY_SOCKET kernel option with two A more appropriate named kernel options for the very distinct A send and receive path. A A options SOCKET_SEND_COW enables VM page copy-on-write based A sending of data on an outbound socket. A A NB: The COW based send mechanism is not safe and may result A in kernel crashes. A A options SOCKET_RECV_PFLIP enables VM kernel/userspace page A flipping for special disposable pages attached as external A storage to mbufs. A A Only the naming of the kernel options is changed and their A corresponding #ifdef sections are adjusted. No functionality A is added or removed. A A Discussed with: alc (mechanism and limitations of send side COW) Users may call this a pointless POLA violation. IMO, the old kernel option that we had for years, more than a decade, should remain and just imply two new kernel options. There shouldn't be any users. Zero copy send is broken and responsible for random kernel crashes. Zero copy receive isn't supported by any modern driver. Both are useless to dangerous. The main problem with ZERO_COPY_SOCKETS was that it sounded great and who wouldn't want to have zero copy sockets? Unfortunately it doesn't work that way. According to alc@ even if zero copy send would work it wouldn't be faster due to page based COW setup being a very expensive operation. Eventually he want's page-based COW to go away. For zero copy send we're trying to come up with a sendfile-like approach where the page is simply wired into kernel space. The application then is not allowed to touch it until the socket buffer has released it again. The main issue here is how to provide feedback to the application when it is safe for reuse. For zero copy receive I've been contacted by np@ to find a way to combine DDP into the socket buffer layer. Trying to work something out that isn't too horrible. A generic approach would hinge on page sized mbufs though. -- Andre ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r241931 - in head/sys: conf kern
On 23 Oct 2012, at 16:05, Andre Oppermann wrote: For zero copy send we're trying to come up with a sendfile-like approach where the page is simply wired into kernel space. The application then is not allowed to touch it until the socket buffer has released it again. The main issue here is how to provide feedback to the application when it is safe for reuse. It's been a few years since I used it, but I thought that aio_write() already provided this. The application may not modify the contents of the memory pointed to by aio_buf until after it has received notification that the write has finished. This happens either via a signal directly, a signal polled by kqueue, or a call to aio_return(). David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r241931 - in head/sys: conf kern
On 10/23/2012 10:05 AM, Andre Oppermann wrote: There shouldn't be any users. Zero copy send is broken and responsible for random kernel crashes. Zero copy receive isn't supported by any modern driver. Both are useless to dangerous. I enabled this a few weeks ago, not knowing it was useless/dangerous. Perhaps an entry in UPDATING to note that this has been renamed and that it may not actually be useful? Also, zero_copy(9) needs updating, as it references ZERO_COPY_SOCKETS. -- Regards, Bryan Drewery bdrewery@freenode/EFNet ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r241931 - in head/sys: conf kern
On 23.10.2012 17:11, David Chisnall wrote: On 23 Oct 2012, at 16:05, Andre Oppermann wrote: For zero copy send we're trying to come up with a sendfile-like approach where the page is simply wired into kernel space. The application then is not allowed to touch it until the socket buffer has released it again. The main issue here is how to provide feedback to the application when it is safe for reuse. It's been a few years since I used it, but I thought that aio_write() already provided this. The application may not modify the contents of the memory pointed to by aio_buf until after it has received notification that the write has finished. This happens either via a signal directly, a signal polled by kqueue, or a call to aio_return(). Indeed, that's one of the ways being explored. It requires the explicit cooperation of the application. I don't think there is any way around that. -- Andre ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r241931 - in head/sys: conf kern
On Tue, Oct 23, 2012 at 05:05:48PM +0200, Andre Oppermann wrote: A There shouldn't be any users. Zero copy send is broken and A responsible for random kernel crashes. Zero copy receive isn't A supported by any modern driver. Both are useless to dangerous. A A The main problem with ZERO_COPY_SOCKETS was that it sounded great A and who wouldn't want to have zero copy sockets? Unfortunately A it doesn't work that way. Okay, it appeared that there are users, even on current@ mailing list during couple of hours of exposition. Can we keep the old option as compatibility? -- Totus tuus, Glebius. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r241931 - in head/sys: conf kern
On 10/23/2012 11:05, Gleb Smirnoff wrote: On Tue, Oct 23, 2012 at 05:05:48PM +0200, Andre Oppermann wrote: A There shouldn't be any users. Zero copy send is broken and A responsible for random kernel crashes. Zero copy receive isn't A supported by any modern driver. Both are useless to dangerous. A A The main problem with ZERO_COPY_SOCKETS was that it sounded great A and who wouldn't want to have zero copy sockets? Unfortunately A it doesn't work that way. Okay, it appeared that there are users, even on current@ mailing list during couple of hours of exposition. In my experience, that is because they are reporting a crash. Can we keep the old option as compatibility? ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r241931 - in head/sys: conf kern
On 23.10.2012 17:21, Bryan Drewery wrote: On 10/23/2012 10:05 AM, Andre Oppermann wrote: There shouldn't be any users. Zero copy send is broken and responsible for random kernel crashes. Zero copy receive isn't supported by any modern driver. Both are useless to dangerous. I enabled this a few weeks ago, not knowing it was useless/dangerous. Perhaps an entry in UPDATING to note that this has been renamed and that it may not actually be useful? Good idea. Will do. Also, zero_copy(9) needs updating, as it references ZERO_COPY_SOCKETS. Already done in r241932. -- Andre ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r241931 - in head/sys: conf kern
On 23.10.2012 18:05, Gleb Smirnoff wrote: On Tue, Oct 23, 2012 at 05:05:48PM +0200, Andre Oppermann wrote: A There shouldn't be any users. Zero copy send is broken and A responsible for random kernel crashes. Zero copy receive isn't A supported by any modern driver. Both are useless to dangerous. A A The main problem with ZERO_COPY_SOCKETS was that it sounded great A and who wouldn't want to have zero copy sockets? Unfortunately A it doesn't work that way. Okay, it appeared that there are users, even on current@ mailing list during couple of hours of exposition. Can we keep the old option as compatibility? No. They are not users. They simply fell for the promise of zero copy which it isn't. It doesn't do what the users believe it does. It's useless for receive and dangerous for send. I have updated NOTES and forwarded it to -current. -- Andre ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
