From owner-svn-src-head@FreeBSD.ORG Tue Oct 23 15:12:36 2012 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BC2518FE; Tue, 23 Oct 2012 15:12:36 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 82E648FC08; Tue, 23 Oct 2012 15:12:35 +0000 (UTC) Received: from [192.168.0.2] (cpc2-cmbg15-2-0-cust445.5-4.cable.virginmedia.com [86.26.13.190]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id q9NFBM6h095459 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 23 Oct 2012 15:11:23 GMT (envelope-from theraven@FreeBSD.org) Subject: Re: svn commit: r241931 - in head/sys: conf kern Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=koi8-r From: David Chisnall In-Reply-To: <5086B24C.9000606@freebsd.org> Date: Tue, 23 Oct 2012 16:11:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201210231419.q9NEJjYH082863@svn.freebsd.org> <20121023144211.GX70741@FreeBSD.org> <5086B24C.9000606@freebsd.org> To: Andre Oppermann X-Mailer: Apple Mail (2.1278) Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, Gleb Smirnoff , src-committers@FreeBSD.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 15:12:36 -0000 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=