So, you think the penalty of processing in the stack, outweighs the performance
gained by having duplicate streams?
You do realise they are being processed in parallel in the stack???
By the time you would start the copy, my modified DMA would be ready under all
scenarios.
Regards,
Mark McCarron
Date: Fri, 17 May 2013 22:35:25 +0200
Subject: Re: [Discuss-gnuradio] Question about UHD driver
From: master.of.knowle...@gmail.com
To: mark.mccar...@live.co.uk
CC: discuss-gnuradio@gnu.org
Hi Mark,
I wasn't assuming you didn't know what a driver is - I was just hoping you'd
try to realize more clearly,
that especially for something like network packets, you need a hardware driver
(and the network stack of the os)
to make use of your dma'ed data.
You're totally right that data from a device needs to be transferred somewhere
before it can be used.
However, I don't think you're right in respect to a parallel DMA always making
your system faster - your second version
of the data still has to be processed by driver/stack (and therefore by the
cpu), so that having it copied into RAM while
your machine is processing the first version is not necessarily faster than
copying the processed version.
In fact, under my caching asumptions, that would even be slower on a single
core system.
On Fri, May 17, 2013 at 8:36 PM, Mark McCarron <mark.mccar...@live.co.uk> wrote:
Marcus,
I was writing the Windows driver for Per Vices Corporation (Phi/Noctar) last
year, I know how drivers work. I should have mentioned that earlier.
What you are missing is the fact that the DMA must occur first before anything
can get to a cache. So, if we are writing to memory in parallel, it is always
going to be faster as this happens long before data gets to the CPU.
Also, just to correct some things, the whole point of DMA is to take the CPU
out of the loop, so the CPU is not used to conduct transfers. It can take part
in scheduling, but the data goes from the device into memory and a pointer is
returned. The FIFO buffer in an app makes use of this pointer.
Regards,
Mark McCarron
Date: Fri, 17 May 2013 20:23:34 +0200
Subject: Re: [Discuss-gnuradio] Question about UHD driver
From: master.of.knowle...@gmail.com
To: mark.mccar...@live.co.uk
CC: discuss-gnuradio@gnu.org
> The ideal scenario is to never copy data and it is achievable, to a degree,
> through proper planning.
I have to strongly disagree with that.
You have to realize what a /driver/ is. And why it is needed:
A driver takes whatever ressources a piece of hardware offers and makes these
ressources usable to actual
application software. Thus: A driver is /necessary/ to convert and transfer
data from "the wire" to something
a program can access without having to know how this particular piece of
hardware works.
This conversion _has_ to happen using the CPU power of the host. Therefore, you
either have to let the driver
do its work on all copies of the device data in RAM, or you just do it once,
and then copy the data using the CPU.
Which is way more intelligent, flexible, well-performing... and what is done in
current architectures.
> If you look at your argument, you are essentially saying that it is better
> to copy than to have a pointer.
In many cases it is.
Example?
You have an arbitrary computer architecture with external memory (this is
desirable unless you want to be
limited to microcontrollers):
RAM---memory bus---cpu
Gigabytes of RAM aren't easy to produce cheaply, and are even harder to access
with low latency.
Therefore, modern CPUs have caches:
RAM --- memory bus --- Cache --- CPU
Those caches are designed to be fast, but are of limited size (for reasons
aforementioned).
Now take your DMA transfer: You instruct the memory controller to write data
from your device to RAM.
That automatically invalidates the cache for this RAM region,if that happens to
be cached, which is
likely, because we're in a scenario where we constantly use data from the
device.
Now assume that this data is relevant to the system. (otherwise we wouldn't
argue over performance, would we?)
So, in the next few microseconds, someone is going to access that newly written
data.
Whether the cache/dma/memory controller updated the cache or not, there will be
one valid copy in the cache soon.
Now, copying that data from RAM address to RAM address is usually a lot faster
than a DMA - because
1) the cache can "hide" the copying by reading from the original address as
long as no writes on either
original or copy take place,
2) access to dma'ed memory only present in RAM is as fast as access to the
cache _at best_.
Therefore, zero copy is not always preferable above having a RAM copy -
especially for stuff that fits into L2 cache
multiple times; for ethernet packets in special.
Hope that mail explained my point of view well enough :)
Greetings,
Marcus
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
