From owner-freebsd-hackers Thu Nov 5 15:39:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA20227 for freebsd-hackers-outgoing; Thu, 5 Nov 1998 15:39:24 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA20222 for ; Thu, 5 Nov 1998 15:39:23 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id PAA00845; Thu, 5 Nov 1998 15:38:41 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199811052338.PAA00845@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: lcremean@tidalwave.net cc: hackers@FreeBSD.ORG Subject: Re: Coprocessor board--which I/O method should I use? In-reply-to: Your message of "Thu, 05 Nov 1998 16:56:13 EST." <19981105165613.A955@tidalwave.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Nov 1998 15:38:41 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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? 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. 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. > 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. -- \\ 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