From owner-freebsd-hackers Fri May 21 16:19:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 89F9214DF2 for ; Fri, 21 May 1999 16:19:38 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA59516; Fri, 21 May 1999 16:19:22 -0700 (PDT) (envelope-from dillon) Date: Fri, 21 May 1999 16:19:22 -0700 (PDT) From: Matthew Dillon Message-Id: <199905212319.QAA59516@apollo.backplane.com> To: Constantine Shkolnyy Cc: "freebsd-hackers@FreeBSD.ORG" Subject: Re: RE: mmap of a network buffer References: <01BEA3AE.EE301C80.stan@osgroup.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :In my view, the problem can be described like this. : :Some applications need to process data from their VA space, on some :devices. If the data is going to/from a file, it looks perfectly :well to copy it into kernel buffers, since the kernel does caching :and improves disk I/O performance. However, there are cases when the :kernel can't be concerned with the data. For example, I have an :encryption/compression processor on PCI board. For each operation, :this processor needs two separated data buffers and performs the :busmaster DMA. The user program is supposed to prepare the buffers :and communicate their location to the kernel mode driver via IOCTL. : :What is more efficient - copy the data to/from the locked kernel :buffers or lock the user buffers "in place" and do processing? :(In my case, I don't even need to _remap_ the buffers, I only need :physical addresses). : :I'd prefer the later, but I don't have sufficient FreeBSD knowledge :to insist that I think right. There may be some principles of this :O/S that I don't currently see that I violate by doing this. : :It would be nice if somebody could give an analysis of the problem. : :Stan Well, all the system buffer paradigm does is wire the pages and associate them with a struct buf. You do not have to map the pages into KVM. It also usually write-protects pages in user space for the duration of the I/O. Even if the pages are mapped into KVM, the overhead is virtually nil if you do not actually touch the associated KVM. I don't think you would notice the difference between using the existing buffer code and rolling something custom. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message