Date: Fri, 24 Nov 2000 21:37:45 -0700 From: "Kenneth D. Merry" <ken@kdm.org> To: Mohan Krishna P <penumetcha@yahoo.com> Cc: hackers@FreeBSD.ORG, pmk@sasi.com Subject: Re: DMA to user process address space!!! Message-ID: <20001124213745.A60779@panzer.kdm.org> In-Reply-To: <20001124062229.1645.qmail@web111.yahoomail.com>; from penumetcha@yahoo.com on Thu, Nov 23, 2000 at 10:22:29PM -0800 References: <20001124062229.1645.qmail@web111.yahoomail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 23, 2000 at 22:22:29 -0800, Mohan Krishna P wrote: > > AFAMUG, all user processes are allocated from the > virtual memory. so DMA to that doesn't make sense. but > is there some way, i can let the kernel know i am > DMAing to an address location and hence keep it in > main memory until some x seconds?? > > > here is why we need this. we are writing software for > a multi-port switch. it can be used in both managed > and unmanaged modes. in managed mode, switch is > connected to host through PCI interface. all packets > that can't > be switched are sent to host. with cach such packet, > switch passes information like the source port of the > packet, it's priority level, whether the packet is > tagged or not etc. > > in normal operation, driver discards this information > and sends the packet to ether_input(). for testing > purpose, we would like to have user-level process, > which receives packets bypassing the ip stack(it isn't > freeBSD way of doing things, but this is only for > testing) and verifies the information. > > if the above thing can't be done, then we will have to > move the user-process functionality to driver. You can do what you're proposing, although it isn't clear that that would necessarily be the best thing to do. There are ways to map memory from the kernel's address space into a userland process address space and vice versa. Just for reference, the pass(4) driver maps things from userland into the kernel with the cam_periph_mapmem() function call in sys/cam/cam_periph.c. There are limits on the amount of data that can be mapped into the kernel with that approach. (128K, which is MAXPHYS) Another way to do get userland memory into the kernel is to map it copy on write. You can get kernel memory into userland via page flipping, if the pages are allocated in the kernel in a manner that allows them to be thrown away. Examples of COW (copy on write) mapping and page flipping are available in the code described here: http://people.FreeBSD.org/~ken/zero_copy Page flipping could also be used to get memory from userland into the kernel, although in that case it might need to be a page trade, unless the userland process was designed to never touch that chunk of memory again. One thing about mapping things COW or page flipping is that you can only do that with page-sized chunks of data. Since you are only passing packets into userland for testing purposes, it may not be necessary to have the high performance (or the page size and alignment issues) that you would gain from one of the methods I described. You can probably get by just as well designing a simple character device interface with a poll() routine that would allow you to select(2) on the file descriptor from a userland process, and wake up whenever a packet arrives. Then your driver can just use copyin(9) and copyout(9) to move things back and forth from the userland process into the driver. As you mentioned, another alternative is to implement the test functionality in the driver. Then you wouldn't have to worry about the performance or alignment considerations of moving things between the kernel and userland. Ken -- Kenneth Merry ken@kdm.org 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?20001124213745.A60779>