From owner-freebsd-current@FreeBSD.ORG Sat Jun 15 11:49:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AE004277 for ; Sat, 15 Jun 2013 11:49:33 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 73B671344 for ; Sat, 15 Jun 2013 11:49:33 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 32BE47300B; Sat, 15 Jun 2013 13:52:43 +0200 (CEST) Date: Sat, 15 Jun 2013 13:52:43 +0200 From: Luigi Rizzo To: Konstantin Belousov Subject: Re: copyin()/copyout() constraints ? Message-ID: <20130615115243.GA60197@onelab2.iet.unipi.it> References: <20130612180115.GA27892@onelab2.iet.unipi.it> <51B8BFC4.303@mu.org> <201306141207.29779.jhb@freebsd.org> <20130614163812.GA50980@onelab2.iet.unipi.it> <51BB925D.2000609@mu.org> <20130615112610.GA59673@onelab2.iet.unipi.it> <20130615113134.GN91021@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130615113134.GN91021@kib.kiev.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Alfred Perlstein , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 11:49:33 -0000 On Sat, Jun 15, 2013 at 02:31:34PM +0300, Konstantin Belousov wrote: > On Sat, Jun 15, 2013 at 01:26:10PM +0200, Luigi Rizzo wrote: > > With "indirect buffers" in netmap/vale, i can eliminate the A->B copy, > > and do A->C with a copyin in the kernel of the host. > > But the per-packet budget is minuscule, and i am afraid that doing > > an unconditional vslock() on each buffer is going to be too expensive > > (and then i should also unwire the page ? > > Using vslock() causes enormous user map fragmentation and should be > avoided. The cost is basically the same as the page fault, since > vslock() is a wrapper around vm_map_wire(), which just calls page fault > handler for each address in region. > > On the other hand, I do not understand how any kernel-side lock would > prevent usermode from unmapping a buffer while other thread in kernel > mode access it. the lock i was talking about in previous emails protects the in-kernel data structures (B, C and the VALE switch), which are manipulated within system calls. The user buffer A is not protected, i am happy to take a page fault in the rare case it happens (and normally it won't because in my application A has been written to just moments before). cheers luigi