From owner-svn-src-all@FreeBSD.ORG Tue Oct 23 15:28:00 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E7C14ACE for ; Tue, 23 Oct 2012 15:28:00 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 509538FC0C for ; Tue, 23 Oct 2012 15:28:00 +0000 (UTC) Received: (qmail 86238 invoked from network); 23 Oct 2012 17:05:59 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 23 Oct 2012 17:05:59 -0000 Message-ID: <5086B775.40702@freebsd.org> Date: Tue, 23 Oct 2012 17:27:49 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: David Chisnall Subject: Re: svn commit: r241931 - in head/sys: conf kern References: <201210231419.q9NEJjYH082863@svn.freebsd.org> <20121023144211.GX70741@FreeBSD.org> <5086B24C.9000606@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, Gleb Smirnoff , src-committers@FreeBSD.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 15:28:01 -0000 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