Date: Fri, 21 May 1999 17:25:31 -0500 From: Constantine Shkolnyy <stan@osgroup.com> To: "freebsd-hackers@FreeBSD.ORG" <freebsd-hackers@FreeBSD.ORG> Subject: RE: mmap of a network buffer Message-ID: <01BEA3AE.EE301C80.stan@osgroup.com>
next in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01BEA3AE.EE301C80.stan>