From owner-freebsd-hackers Sun Dec 5 21: 6:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 8C0AC1538E; Sun, 5 Dec 1999 21:06:30 -0800 (PST) (envelope-from kvandel@cs.duke.edu) Received: from wookie.vandelden.com (IDENT:root@s-kvandel.cs.duke.edu [152.3.134.91]) by duke.cs.duke.edu (8.9.1/8.9.1) with SMTP id AAA23279; Mon, 6 Dec 1999 00:06:21 -0500 (EST) From: kvandel Reply-To: kvandel@cs.duke.edu Organization: Duke University To: Mike Smith Subject: Re: fxp, xl driver question .. (routing) Date: Sun, 5 Dec 1999 23:38:55 -0600 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: <199912060440.UAA00678@mass.cdrom.com> In-Reply-To: <199912060440.UAA00678@mass.cdrom.com> Cc: freebsd-hackers@FreeBSD.ORG MIME-Version: 1.0 Message-Id: <99120600010702.01504@wookie.vandelden.com> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 05 Dec 1999, you wrote: > > > 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. I don't want to interrupt the devices.. which would require the transaction to reoccur... I do agree(from the book PCI System Architecture), the Master Latency Timer should be decreased, but I still need the DMA transactions to complete sooner from the time GNT# is removed by the arbiter. > 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. I don't think the NIC will do this... However it it possible... From 3com docs, the 3c509bs don't... But I could probably reorder the dma requests to force seperate transactions... maybe, maybe not. > 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. I understand how it is working, but the I still beleive smaller DMA transactions, while somewhat inefficient, will shorten the latency to something reasonable. > 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( > I agree. If I knew I could avoid handshaking the device, I would skip it... It takes 20+% of the forwarding time.. I have another question: Is there a way to get the compiler to do a non blocking mem read ? load to a hardwired zeroed register? thanks a bunch, kurt > > > > -- > \\ 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 -- uname -a > Linux wookie.vandelden.com 2.2.13 #1 < To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message