From owner-freebsd-hackers Mon Nov 9 14:25:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA29996 for freebsd-hackers-outgoing; Mon, 9 Nov 1998 14:25:08 -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 OAA29988 for ; Mon, 9 Nov 1998 14:25:05 -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 RAA02703; Mon, 9 Nov 1998 17:24:34 -0500 (EST) (envelope-from lee) Message-ID: <19981109172434.A2380@tidalwave.net> Date: Mon, 9 Nov 1998 17:24:34 -0500 From: Lee Cremeans To: Mike Smith , hackers@FreeBSD.ORG Cc: hackers@FreeBSD.ORG Subject: Re: Encryption coprocessor, part 2. Reply-To: lcremean@tidalwave.net References: <19981109151423.A2157@tidalwave.net> <199811092033.MAA00693@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811092033.MAA00693@dingo.cdrom.com>; from Mike Smith on Mon, Nov 09, 1998 at 12:33:57PM -0800 X-OS: FreeBSD 3.0-CURRENT X-Evil: microsoft.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Nov 09, 1998 at 12:33:57PM -0800, Mike Smith wrote: > It sounds from your previous messages as though the control buffers are > actually associated with the data buffers, so you might want to unify > them. They can be, but the DMA channels on this chip only move 64k at a time (I'd run into trouble if I had a full IP packet and the command header together), and besides, it has a channel dedicated to writing the command buffers into the chip. So the way I see it, I'd have 4 synch'd queues, a list saying which slots are in use/dirty/free, and a way to check which buffer goes with which session (I'm thinking of keeping a list of sessions). Keeping buffers and DMA descriptors together would be interesting, tho, but I think I can figure something out. I'm thinking something like this when I build the lists: /* This is the struct for a DMA descriptor. We stick the pointer for the associated buffer directly into mybuf->buf. */ struct mybuf { unsigned short flags; #define DESC_FLAGS_VALID 0x8000 /* this descriptor is ready for use */ #define DESC_FLAGS_JUMP 0x4000 /* descriptor points to another desc */ #define DESC_FLAGS_LAST 0x2000 /* last desc in the list/ring */ #define DESC_FLAGS_MASKDONE 0x0200 /* don't interupt when this desc finishes */ unsigned short length; /* 16 bits -- 64k */ caddr_t addr; /* physical addr of buf or next desc */ } Note that this is the actual structure of a 7751 DMA descriptor (though I think I may have the byte order/alignment off). What I'd do, then, is make an array struct mybuf[NUM_SLOTS] cmd_ring and feed that address to the chip, assuming this is done in wired memory. (contigmalloc and vtophys (finally) are my friends here, I'd think). Then I'd go thorugh and allocate buffers for each slot in the list. I feel funny about allocating all that wired-down memory, though.. Does this sound right? -- 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