Date: Tue, 12 Aug 1997 09:05:09 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: ccsanady@friley01.res.iastate.edu (Chris Csanady) Cc: terry@lambert.org, freebsd-hackers@FreeBSD.ORG Subject: Re: DISCUSS: interface for raw network driver.. Message-ID: <199708121605.JAA25453@phaeton.artisoft.com> In-Reply-To: <199708120321.WAA04402@friley01.res.iastate.edu> from "Chris Csanady" at Aug 11, 97 10:21:18 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >The mmap'ing has long been used to save the copy overhead, by causing > >the uiomove() to take the transfer fault in kernel space (the user > >space reference only exists to get a DT entry of some kind). > > DT? Sorry; shorthand: Descriptor Table, LDT/GDT entries... > >If you mapped a file into a process (specifically, grabbed some > >anonymous pages from /dev/zero), it seems to me that it would > >provide the same facilities, without the danger that someone else > >could stomp on your memory region which was pinned in the KVA space. > > This is a good point. Although there are a few issues. First of all, > If I just grabbed pages from zero, they wouldn't be contiguous. This > makes it more difficult in that the driver will have to use the physical > addresses when dma'in in or out--which means scatter gather to an > arbitrary number of segments. Also, unless only one process were > allowed access to the device at a time, you couldn't know which segment > an arbitrary packet should be dma'ed into. This may be a reasonable > restriction though. Urg. You need a "MAP_CONTIG" argument to mmap(), it seems... As far as multiple processes are concerned, it's not really a problem; you could mmap() a real file instead, or you could pass the descriptor or use vfork(), etc.; there are a lot of ways around that one. But you're right, it's a pretty reasonable restriction without that. > >Obviously, if the mmap() stuff was fixed, the kernel mapping > >would go away, so this might be a consideration. > > The above is mainly why all the buffers come straight from the kernel. > It is the only way to allocate a contiguous chunk of memory upon boot. Yep; there needs to be a MAP_CONTIG. I could see using it for user space DMA for other things as well: like camera drivers. > >On the other hand, the per-process descriptor table must be present > >for your process to be running anyway, and it's unlikely to be > >LRU'ed out -- especially if, on I/O request, you pin the pages > >and have the completion unpin the pages? > > The general idea is to have a dual mapping throughout the entire time > that you are using the device. Then you should pin the pages. If you are DMA'ing (duh! I should have realized this last time!), then you are dealing with physical addresses. So pinning needs to be a side effect of MAP_CONTIG (makes sense; it wouldn't *be* contiguous if it were swapped. 8-)). I think John Dyson touched mmap(0 last... ;-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708121605.JAA25453>