Date: Wed, 11 Feb 1998 11:43:52 -0800 From: David Greenman <dg@root.com> To: Brian McGovern <bmcgover@cisco.com> Cc: hackers@FreeBSD.ORG Subject: Re: Mapping phyical memory in to the PCI address range... Message-ID: <199802111943.LAA21296@implode.root.com> In-Reply-To: Your message of "Wed, 11 Feb 1998 14:36:43 EST." <199802111936.OAA02653@bmcgover-pc.cisco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>Lets make sure I'm following you here.... :) There are too many components >labeled 'CPU' to throw it around lightly. What I _think_ you're saying >(I'm starting to sound like a psychiatrist) is that it makes the most sense >to map the card's memory in to the PCI address space, let the on-board CPU >access its (local) RAM, and then copy large chunks across the PCI bus, which >is how the card is manipulated in the current driver. > >The "win" I'm going for is to keep the host CPU load to a bare minimum. To >be honest, barring overloading the PCI bus, I could care less about the card's >CPU having to work hard, so long as it has enough time to move the data. So, >to summarize: > > >Host CPU Board CPU Is it a good thing? (tm) > >BUSY DMA'ing Data Driving the UARTs via Its ok. Thats how we do it > local RAM today > >Busy Doing other Busy driving UARTs and So long as we don't loose >things,occationally DMAing in to host throughput, this is >moving data in/out of memory optimal to me. >clists/buffers. > >Busy moving data Busy moving Data Not what I want. >around around It takes CPU time to initialize the DMA descriptors and device registers in order to start a DMA operation. This overhead will be higher than just copying out the characters to the PCI device directly like you do now if the number of characters is too small. It's not uncommon to actually use a hybrid approach with a threshold such that if there are less than n chars to output, then do it directly to the mapped PCI memory, otherwise do a DMA to the card. Does this make sense? -DG David Greenman Core-team/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802111943.LAA21296>