Date: Sat, 15 Jun 2013 14:31:34 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: Alfred Perlstein <bright@mu.org>, freebsd-current@freebsd.org Subject: Re: copyin()/copyout() constraints ? Message-ID: <20130615113134.GN91021@kib.kiev.ua> In-Reply-To: <20130615112610.GA59673@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>
next in thread | previous in thread | raw e-mail | index | archive | help
--57SHPaztv6dlLu/a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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. IMO you would be much better served with either with proc_rwmem(), as discussed before, or direct use of vm_fault_quick_hold_pages() and uiomove_fromphys() afterward. vm_fault_quick_hold_pages() also makes you code immune against usermode doing any unmap or mapping over the passed buffer. --57SHPaztv6dlLu/a Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRvFCVAAoJEJDCuSvBvK1Bf5AP/3CWeMjp22hzlz7QgVusqZHx sKJEduia72R+IXes1iCK96jxvZgRqEHMZxjx2C+fLAA88TkvVYJRpbC2pb3wpv6L SzF5uPn2WMZGfzMD3OqNhTOFThPC5bSp4ZvYa4aNMup9ru7I5KLtWOwkJfqdpHYk MBBnhP+t+61eso5X8vaPbE2ruU2kKwa7TBQ2htkA/j+t+IHkNdqUxHYe2RT0m71j 31lAdW77jvSb9B0KSjxFna4BIDfY/qDElApIcyEwwsJ/zMy3QTnR6Iz7rlLviB0q E6xWJzuKYaKKd4qhQEDTY/60MTrDb9vLjsmFkwi7BwamvelK3YGCiSepyNb4mnKT m+ACtmv2/lmUUvyT3qdn79TQjYi3l3KAaWq77eyD7+WpOvjZJqurV29hm0cOBLJ1 Fgf37oJaHyy1lFT26jIFshjXdcBzNXOPeOM8SkxHJk+q+i8eXvHsBiTcGmKbtRYE 4Prjr2AqYkd75C7ymb4nONDvEyY9QlLgMEe9ASrU9iJRWHNuxh71BPRDUHNh+qDw xsx9F1JRFVEfIm9WThgmHE+G6Glt7JZOdHcVtcRPfxzxghg1zlXQqKGSt/QtYBrV fN7jmDHM0UHYqSjcFJXHAJN4LIJGnfjWGc0A0bHPZdG2dp4ztSDRl8APssPwCGot HgROC/OyM7Dr78j1voFc =i/hZ -----END PGP SIGNATURE----- --57SHPaztv6dlLu/a--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130615113134.GN91021>