From owner-freebsd-hackers Fri May 21 15:24:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from osgroup.com (unknown [38.229.41.6]) by hub.freebsd.org (Postfix) with ESMTP id 17B4114BB8 for ; Fri, 21 May 1999 15:24:25 -0700 (PDT) (envelope-from stan@osgroup.com) Received: from stan166 ([38.229.41.237]) by osgroup.com (8.7.6/8.6.12) with SMTP id RAA13171 for ; Fri, 21 May 1999 17:12:44 -0500 Received: by localhost with Microsoft MAPI; Fri, 21 May 1999 17:25:32 -0500 Message-ID: <01BEA3AE.EE301C80.stan@osgroup.com> From: Constantine Shkolnyy Reply-To: "stan@osgroup.com" To: "freebsd-hackers@FreeBSD.ORG" Subject: RE: mmap of a network buffer Date: Fri, 21 May 1999 17:25:31 -0500 Organization: Ashley Laurent, Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > My hope was to map the user's buffer into kernel space so that I could do > event driven io on the socket without having to context switch to an aiod > for every io operation. Is this really a bad idea? I am a little > concerned about running out of kernel address space, but I don't think > that's an immediate problem. > > Such an implementation would lend itself to doing zero-copy writes async > writes with some frobbing of the send routines. It would also bypass > some > of the messing around done to do socket buffers--that is, there would not > be a limit per se on socket buffering for writes since they would be > mapped user space. One might want to put arbitrary limits in place to > ensure that an unreasonable amount of memory isn't locked. > > Thoughts? 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message