From owner-freebsd-hackers Sun Dec 5 20:38:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (castles554.castles.com [208.214.165.118]) by hub.freebsd.org (Postfix) with ESMTP id 112E914DF1 for ; Sun, 5 Dec 1999 20:38:55 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id UAA00678; Sun, 5 Dec 1999 20:40:48 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912060440.UAA00678@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: kvandel@cs.duke.edu Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Sun, 05 Dec 1999 16:37:38 CST." <99120516514304.01102@wookie.vandelden.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 05 Dec 1999 20:40:48 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Question, > > I am a graduate student at Duke University. Currently, I am part of a team to > build a terabit router using a cluster connected with Myrinet. One aspect of > the project is to tune the devices & drivers to perform cooperatively... In a > routing situation, the 1500B dma takes roughly 11us over PCI 32/33Mhz. If the > processor (driver) is checking the command accept status of a NIC, it can > take a "long" time to get a response from the NIC. For gigabit routing, you > have to roughly processes 1pkt/ 8-10us . For starters, I changed up the > driver code in fxp_start to break up a large dma transactions into smaller > chunks,.. to make bus arbitration work using a finer grain time slice. Hence, > the processor stalls less when it checks if a NIC command was accepted. > > The question: Why doesn't this work... it seem so straight forward... I'm not sure about the code in question, but the basic assumptions you're making about PCI's behaviour are flawed. To achieve the goal you're trying to, you need to reduce the value of the PCI bus latency timer for the peripheral(s) that you're hoping to interrupt. Breaking up the DMA transactions leaves you vulnerable to the PCI peripheral noticing that the two segments are contiguous and coalescing them again into a single master write. Also, you don't want the (high) overhead of forcing a re-arbitration all the time, rather you want to guarantee the worst-case cycle time involved in polling the peripheral. Again, to achieve this, you want to look at how the PCI bus latency timer works and use it instead. You will always get the best performance out of PCI by avoiding _anything_ that involves arbitrating for the bus. PCI bus transactions are reasonably expensive to start. 8( -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message