Date: Mon, 06 Dec 1999 00:05:53 -0800 From: Mike Smith <msmith@freebsd.org> To: kvandel@cs.duke.edu Cc: Mike Smith <msmith@FreeBSD.ORG>, freebsd-hackers@FreeBSD.ORG Subject: Re: fxp, xl driver question .. (routing) Message-ID: <199912060805.AAA01467@mass.cdrom.com> In-Reply-To: Your message of "Sun, 05 Dec 1999 23:38:55 CST." <99120600010702.01504@wookie.vandelden.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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... Er, as I understand your original requirement this is exactly what you want to do - you want to push them off the bus so that the CPU can poll a status register on a given card. > 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. The only case where the device will _not_ release the bus on loss of #GNT is when its latency timer has not yet expired. This is my point; you can guarantee an upper bound on the time from #GNT loss to bus release _only_ by changing the latency timer. Dropping the size of all of your DMA transactions increases your losses due to arbitration delays, because the device will (normally) _always_ give up the bus at the end of a DMA transaction. > > 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. No, this is basically wrong. Sure, shortening your DMA transactions absurdly will give you some control over burst length, but you'd have to reduce them to less than the latency-timer-protected window before you noticed any effect, and the overhead-related losses would be painful. Consider the optimal situation; you have a descriptor set up for a ~1500 byte DMA, and the latency timer is set to 32 cycles. The worst-case latency is then a little over 1us (including arbitration). To do any better than this, you need to reduce your DMA burst size to less than 32/4 or 128 bytes. This increases your arbitration overhead by a factor of more than 10. This is a _constant_ loss factor, and at this point you still haven't actually gained anything. To improve your worst-case latency by a factor of 2, you have to increase your arbitration loss to twenty times that of the 'optimal' case. I can assure you that PCI is not very efficient when you are only bursting 64 bytes at a time. 8) Conversely, you can achieve the same latency reduction by setting the latency timer to 16, without increasing your overheads there. (This isn't actually entirely true, as you may run into busmaster ping-pong with more than one in the system, but you'll get this with reduced DMA bursts as well.) > > 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.. You may want to give up and use another device... > 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? I'm not sure what you're talking about here. "non-blocking" against what? -- \\ 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912060805.AAA01467>