Date: Sat, 15 Jun 2013 13:52:43 +0200 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Alfred Perlstein <bright@mu.org>, freebsd-current@freebsd.org Subject: Re: copyin()/copyout() constraints ? Message-ID: <20130615115243.GA60197@onelab2.iet.unipi.it> In-Reply-To: <20130615113134.GN91021@kib.kiev.ua> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130615115243.GA60197>