From owner-freebsd-hackers Tue Aug 12 09:09:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA01065 for hackers-outgoing; Tue, 12 Aug 1997 09:09:51 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA01060 for ; Tue, 12 Aug 1997 09:09:46 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA25453; Tue, 12 Aug 1997 09:05:09 -0700 From: Terry Lambert Message-Id: <199708121605.JAA25453@phaeton.artisoft.com> Subject: Re: DISCUSS: interface for raw network driver.. To: ccsanady@friley01.res.iastate.edu (Chris Csanady) Date: Tue, 12 Aug 1997 09:05:09 -0700 (MST) Cc: terry@lambert.org, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199708120321.WAA04402@friley01.res.iastate.edu> from "Chris Csanady" at Aug 11, 97 10:21:18 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >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.