[cap-talk] DMA vs programmed I/O (was: Midori in The Register)

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Wed Aug 6 16:34:06 CDT 2008


Kenneth Hamer-Hodges wrote:
> Adding a second DMA version of typed hardware leads to a second set of
> mechanism at risk and question about delegation to the DMA level open up
> another Pandora's Box. 
> With multi core solution so easily available today this simplicity and
> uniformity remain the best option for building a Trusted Computer Base.

Given that existing systems use DMA, and obtain a significant performance
advantage from doing so *for any given number of cores*, and that new
systems must be able to compete on performance, it seems unlikely that a
new system design that was unable to use DMA could be successful.

I don't often make arguments in favour of performance at the expense of
simplicity, but here the performance advantage (perceived and actual) is
just too great. For a system using programmed I/O to be able to compete,
the hardware would need to have enough general-purpose cores that you
don't have anything worthwhile to do with some of them apart from I/O.
Even that assumes that the required I/O bandwidth won't increase as the
number of cores does, which is probably not a valid assumption,
especially for the applications that are most in need of high performance.

If anything, the importance of having specialized I/O "cores" (whether
or not they look like conventional DMA controllers) increases with
multicore, because this specialization is a more efficient use of the
available chip area and power budget: a general-purpose core is area-
and power-inefficient for doing I/O, and an I/O core can't be made
to do general computation without increasing its area and power usage.
Actually it makes some sense to further specialize the I/O cores to
handle specific physical-layer protocols, as the Tile64
<http://www.tilera.com/products/processors.php> does, for example.
(I have no connection with Tilera.)

-- 
David-Sarah Hopwood


More information about the cap-talk mailing list