Date: Thu, 05 Nov 1998 23:04:00 -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: <199811060704.XAA00536@dingo.cdrom.com> In-Reply-To: Your message of "Thu, 05 Nov 1998 20:17:33 EST." <19981105201733.B1450@tidalwave.net>
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. That's not a good spec to be writing to. Get an answer. 8) > > 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. > > 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. > > > 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. Not at all; you'd just leverage the private address space off the virtual interface to present an arbitrary number of virtual loopback interfaces, each forming part of the "pipe" for each connection. Probably too much of a headgame though. -- \\ 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?199811060704.XAA00536>