Date: Fri, 6 Nov 1998 08:28:35 -0500 From: Lee Cremeans <lee@st-lcremean.tidalwave.net> To: Mike Smith <mike@smith.net.au> Cc: hackers@FreeBSD.ORG Subject: Re: Coprocessor board--which I/O method should I use? Message-ID: <19981106082835.A2926@tidalwave.net> In-Reply-To: <199811060704.XAA00536@dingo.cdrom.com>; from Mike Smith on Thu, Nov 05, 1998 at 11:04:00PM -0800 References: <19981105201733.B1450@tidalwave.net> <199811060704.XAA00536@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 05, 1998 at 11:04:00PM -0800, Mike Smith wrote: > > > If so, and if it uses memory-mapped I/O, I would consider having the > > > device driver allow memory-mapping the I/O region into the user process > > > space. If you combined that with an interrupt handler that poked the > > > process (eg. with a signal or using a callin/semaphore) you'd avoid > > > multiple copies and gain performance. > > > > Ah...but this chip is interesting. It's a Hi/fn 7751 (www.hifn.com for the > > data sheet, it's in PDF), and it uses IP-like headers to get commands from > > the host--you could technically stream them in with data. Thing is, the chip > > has 4 DMA channels: one for command headers, one for source (raw) data, one > > for destination (processed) data, and one for "result" structures. TO top it > > off it does scatter-gather DMA, meaning that mapping the buffers to user > > space would be interesting (since, unlike a network card, this thing doesn't > > have any common buffer memory on the card or in the chip). > > > > So, I guess my question is how to get the packets down to the chip in an > > efficient fashion. I keep thinking a struct with the necessary pointers in > > it would do...the driver could lock down the pages (is this necessary? My > > mind is polluted with NT driver programming horrors :( ), then vtophys them > > to make the lists, and send that on to the card. > > 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.) 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. > > > Alternatively, appearing as a character device would be the way to go. > > > You face some interesting problems if the board supports multiple > > > simultaneous streams, in that you'll need to devise a technique for > > > multiplexing your I/O. > > > > It does; the chip has different "contexts" for each stream going through it, > > which it stores in dedicated RAM on the board. However, these requests can > > be packetized fairly easily, I'd say; the firewall/VPN app would do the > > serialization/prioritizing (it'd more than likely be the only app on the > > machine), and the driver would handle moving the data > > around. > > 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. 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. -- Lee Cremeans -- Manassas, VA, USA (WakkyMouse on DALnet and WTnet) A! JW223 YWD+++^ri P&B++ SL+++^i GDF B&M KK--i MD+++i P++ I++++ Did $++ E5/10/70/3c/73ac/95/96 H2 PonPippi Ay77 M | mailto:lcremean@tidalwave.net http://st-lcremean.tidalwave.net | Powered by FreeBSD 3.0-CURRENT 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?19981106082835.A2926>