Date: Mon, 9 Nov 1998 17:24:34 -0500 From: Lee Cremeans <lee@st-lcremean.tidalwave.net> To: Mike Smith <mike@smith.net.au>, hackers@FreeBSD.ORG Cc: hackers@FreeBSD.ORG Subject: Re: Encryption coprocessor, part 2. Message-ID: <19981109172434.A2380@tidalwave.net> In-Reply-To: <199811092033.MAA00693@dingo.cdrom.com>; from Mike Smith on Mon, Nov 09, 1998 at 12:33:57PM -0800 References: <19981109151423.A2157@tidalwave.net> <199811092033.MAA00693@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981109172434.A2380>