Date: Thu, 5 Nov 1998 20:17:33 -0500 From: Lee Cremeans <lee@st-lcremean.tidalwave.net> To: Mike Smith <mike@smith.net.au>, hackers@FreeBSD.ORG Subject: Re: Coprocessor board--which I/O method should I use? Message-ID: <19981105201733.B1450@tidalwave.net> In-Reply-To: <199811052338.PAA00845@dingo.cdrom.com>; from Mike Smith on Thu, Nov 05, 1998 at 03:38:41PM -0800 References: <19981105165613.A955@tidalwave.net> <199811052338.PAA00845@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 05, 1998 at 03:38:41PM -0800, Mike Smith wrote: > > I'm writing a device driver for a board we're de3veloping at work that does > > encryption and compression in hardware. This board is going to be used in > > embedded applications (it's a PCI board), like VPNs and firewalls, so it'll > > be handling a good amount of data. For something like this, what would be > > the best way to do I/O from userland to the card? I'm thinking character > > would do, but I'd appreciate other opinions, and also being told if I'm > > off-base. Also, I'd need to know which interrupt level (net, bio, tty, etc.) > > this thing should be in. > > Will the card only be accessed by a single process at one time? It should be. Most firewall programs I've seen are monolithic. > 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. > 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. > > PS: this card is just a processor board, it is not a network protocol > > controller. > > That doesn't mean that you couldn't make it look like a loopback > interface and route stuff through it, though I doubt it'd be the > easiest way to go. Right; this would also hamper some of the interesting features of the card, such as being able to use different encryption keys for each packet. -- 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?19981105201733.B1450>