Re: PCI DMA into USER space

From: Richard B. Johnson (root@chaos.analogic.com)
Date: Wed Jun 14 2000 - 10:46:04 EST


On 14 Jun 2000, Jes Sorensen wrote:

> >>>>> "Richard" == Richard B Johnson <root@chaos.analogic.com> writes:
>
> Richard> The PCI bridge is bus-mastering hardware. Without the use of
> Richard> the CPU at all, hardware writes from a device, write directly
> Richard> to RAM wherever you have specified when setting up the PCI
> Richard> device. You don't have to suck data through a low-bandwidth
> Richard> port using DMA. If you need to copy data, usually the case,
> Richard> you have to copy it anyway. It is dumb to incur the DMA setup
> Richard> time for memory-to-memory DMA, then wait for the hardware to
> Richard> do it. Instead, you just use the data directly.
>
> Rubbish, PCI shared memory is *slow* you want DMA. Granted, PCI shared

Hardly rubbish.

> memory is faster than the brain dead IO ports but it's far from as
> fast as streaming DMA or in particular host memory access. In a modern
> PC you easily get 300-400MB/sec of real bandwidth between the CPU and

You can easily get over 1,000 MB/sec between RAM and the CPU. This
is relevent only during a copy operation. It has nothing to do with DMA.

> system memory whereas you'll get far less than 100MB/sec when
> accessing the PCI memory (maybe half if you're lucky). As such it is

A 33MHz, 32-bit Revision 2.2-compliant PCI bus gives you 132 MB/second.
That's the spec. There is no way to slow it down except by a disconnect.

> quite often worth it to DMA to host memory and then let the CPU access
> data from there.
>

Not ever. The DMA controllers can't work at CPU speed because they can't
keep the bus forever like the CPU can. The fly-by mode supported by
some chips allows you to get one transfer per clock. The clock is only
16 MHz (max), not the 33 MHz of PCI (some PCI even do 66 MHz although
they are doing it on "invented" specifications).

Tested speeds of a 400MHz machine with P100 RAM are:

Testing shared memory copy from 000A0000...done
Testing shared memory copy from 000B0000...done
Testing shared memory copy from 000B8000...done
Testing shared memory copy from 000C0000...done
Testing shared memory copy from 000C8000...done
Testing shared memory copy from 000D0000...done
Testing shared memory copy from 000D8000...done
Testing shared memory copy from 000E0000...done
Testing shared memory copy from 000E8000...done
Testing checksum...done
Testing memory copy...done
I/O port speed...done

                 chksum speed = 676 Mb/s ( Linux TCP/IP checksum )
                     RAM copy = 1680 Mb/s ( Malloc'd buffers )
               I/O port speed = 655 kb/s ( Printer port )
     Shared RAM copy 000A0000 = 1 Mb/s ( Screen registers )
     Shared RAM copy 000B0000 = 1 Mb/s ( Nothing there )
     Shared RAM copy 000B8000 = 3 Mb/s ( Screen regen buffer )
     Shared RAM copy 000C0000 = 614 Mb/s ( PCI shared RAM )
     Shared RAM copy 000C8000 = 17 Mb/s ( Shadowed VGA code )
     Shared RAM copy 000D0000 = 615 Mb/s ( PCI shared RAM )
     Shared RAM copy 000D8000 = 1 Mb/s ( Nothing there )
     Shared RAM copy 000E0000 = 17 Mb/s ( Shadowed SCSI BIOS )
     Shared RAM copy 000E8000 = 17 Mb/s ( Shadowed SCSI BIOS )

Cheers,
Dick Johnson

Penguin : Linux version 2.3.36 on an i686 machine (400.59 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:31 EST