Date: Fri, 06 Nov 1998 12:44:31 -0800 From: Mike Smith <mike@smith.net.au> To: lcremean@tidalwave.net Cc: Mike Smith <mike@smith.net.au>, hackers@FreeBSD.ORG Subject: Re: Coprocessor board--which I/O method should I use? Message-ID: <199811062044.MAA00773@dingo.cdrom.com> In-Reply-To: Your message of "Fri, 06 Nov 1998 08:28:35 EST." <19981106082835.A2926@tidalwave.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Yick. You really don't want to have to deal with that. You should be > > OK just using uiomove to pull stuff in from user space to a local pool > > of buffers. If the card does scatter-gather and supports multiple > > outstanding commands, you should be able to keep its pipe full all the > > time. > > All righty...are there any good examples of a card that does this? (And the > method I mentioned is basically what NT makes you do. It's extremely 0dd...I > really should have tried writing for BSD first.) Euww. Wiring user pages is OK *if* your VM system is fast enough, but it leaves you open to *serious* abuse. > I have been looking at > wpaul's if_tl.c code, and it's been helpful, but since I'm writing for > something that's not a NIC, and I don't want my head to swim in the loopback > idea, I've been avoiding using mbuf I/O. The ideas are still basically applicable; your *write routine will take writes and copy them into internal buffers; you will want to make some policy decisions about buffer sizes, write atomicity, etc. You'll want to allocate these buffers at startup time, and probably store the physical address of the buffer in the buffer control structure. The internal buffers then get fed to the processor via the interrupt handler, and completed buffers are put on the 'done' queue ready for reading. > > How much context RAM does it have? Can you page to/from the context > > memory? If you're doing the mux/demux in the driver and you only have > > one consumer, you will probably have to wrap the read/write data with a > > header structure to identify the logcal channel it's on. The only > > alternative is always having more device nodes than that you have > > connections. > > You can send commands to read and write the contexts through the DMA, but > you can't map it into PCI address space if that's what you're asking. No. The issue is simply that unless you want to limit the total number of simultaneous connections you support to the capabilities of the device, you'll need to be able to page contexts in and out. > Also, > Hi/fn recommends locking the CRAM and letting the chip manage it, since > context is intermediary data (like a glorified carry register), not actual > commands or data. As for contexts, the command header has the context in > it, and I figure if you keep the pointers together, you'll be OK. The card > can have up to 2MB context RAM. How big is a context? Do you have any idea whether you'll be limited here? At any rate, adding context paging will be reasonably simple at a later stage it seems. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com 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?199811062044.MAA00773>