From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Edmondson Subject: Re: RFC: [0/2] Remove netloop by lazy copying in netback Date: Tue, 20 Mar 2007 11:50:12 +0000 Message-ID: <20070320115011.GR29576@cheesecake.uk.sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Xen Development Mailing List , Herbert Xu List-Id: xen-devel@lists.xenproject.org On Tue, Mar 20, 2007 at 10:27:48AM +0000, Keir Fraser wrote: > On 20/3/07 10:22, "Keir Fraser" wrote: > > One other thought I had -- does the Linux network stack ever modify date > > residing outside the main skbuff data area (i.e., data in fragments)? If it > > ever does, wouldn't your delayed copy in netback potentially race such > > updates? If the Linux network stack guarantees never to do such a thing, > > that would be nice for us. :-) > > Scrub that question: we already map the grants read-only, so the network > stack can't be trying to write to fragments. The Solaris stack expects to be able to write to received packets and I have a hack in our front and back end drivers to permit a writable mapping of front->back buffers in preference to a copy (it's declared using a feature flag, so a guest that doesn't do it still works). I've resisted meddling in the fault handler, but I guess that I should spend some time there in case it's a straightforward addition... dme.