From owner-freebsd-hackers Thu Nov 5 17:17:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA00252 for freebsd-hackers-outgoing; Thu, 5 Nov 1998 17:17:55 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from st-lcremean.tidalwave.net (host-e186.tidalwave.net [208.213.203.186] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA00238 for ; Thu, 5 Nov 1998 17:17:50 -0800 (PST) (envelope-from lee@st-lcremean.tidalwave.net) Received: (from lee@localhost) by st-lcremean.tidalwave.net (8.9.1/8.8.8) id UAA01614; Thu, 5 Nov 1998 20:17:33 -0500 (EST) (envelope-from lee) Message-ID: <19981105201733.B1450@tidalwave.net> Date: Thu, 5 Nov 1998 20:17:33 -0500 From: Lee Cremeans To: Mike Smith , hackers@FreeBSD.ORG Subject: Re: Coprocessor board--which I/O method should I use? Reply-To: lcremean@tidalwave.net References: <19981105165613.A955@tidalwave.net> <199811052338.PAA00845@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811052338.PAA00845@dingo.cdrom.com>; from Mike Smith on Thu, Nov 05, 1998 at 03:38:41PM -0800 X-OS: FreeBSD 3.0-CURRENT X-Evil: microsoft.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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