From owner-freebsd-hackers Thu Feb 12 17:06:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA14690 for hackers-outgoing; Thu, 12 Feb 1998 17:06:14 -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 RAA14642 for ; Thu, 12 Feb 1998 17:06:04 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id RAA05338; Thu, 12 Feb 1998 17:04:40 -0800 (PST) Message-Id: <199802130104.RAA05338@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Brian McGovern cc: Mike Smith , dg@root.com, hackers@FreeBSD.ORG Subject: Re: Mapping phyical memory in to the PCI address range... In-reply-to: Your message of "Thu, 12 Feb 1998 19:51:54 EST." <199802130051.TAA10455@bmcgover-pc.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 12 Feb 1998 17:04:39 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I guess I've mis-represented some terminology, so I think we're off on a bit > of a tangent. Let me start over, and hopefully, we'll get on track. No, just not enough data. > These buffers can be moved by reprogramming the PLX9060 to use a memory > address on the HOST so long as its visable on the PCI bus. Once this is done, > the BOARD's CPU will handle transferring the data to these queues, thereby > eliminating the need for the HOST CPU to copy the data from the board. Aha, but what is significant is that once you have set this buffer up you don't have to again. > The question at hand was whether it was 'faster' to have the board transfer > the data to the HOST's memory, so that a bcopy or b_to_q() call would > be moving data from HOST memory to HOST memory, or is the gain insufficient, > and its more prudent to have the HOST CPU move the data from the board > itself. It will definitely be faster to have the board push to host memory. > The goal is to reduce the HOST CPU time spent moving data around without > affecting throughput to the board. Yup. If you have the data in main memory, you will have to make sure that your access techniques allow you to exclude the board interfering while you play with its control structures. > There, now that that is said, is the picture any clearer? Yes. If host CPU usage is currently an issue, this will reduce the overheads to a degree. -- \\ 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 hackers" in the body of the message