Re: [RFC] [PATCH 0/3] ioat: DMA engine support

[Jeff Garzik <jgarzik@pobox.com>]

Andi Kleen wrote:
> Longer term the right way to handle this would be likely to use
> POSIX AIO on sockets. With that interface it would be easier
> to keep long queues of data in flight, which would be best for
> the DMA engine.

Agreed.

For my own userland projects, I'm starting to feel the need for network 
AIO, since it is more natural:  the hardware operations themselves are 
asynchronous.


> > In addition to helping speed up network RX, I would like to see how 
> > possible it is to experiment with IOAT uses outside of networking. 
> > Sample ideas:  VM page pre-zeroing.  ATA PIO data xfers (async copy to 
> > static buffer, to dramatically shorten length of kmap+irqsave time). 
> > Extremely large memcpy() calls.
>
>
> Another proposal was swiotlb.

That's an interesting thought.


> But it's not clear it's a good idea: a lot of these applications prefer to 
> have the target in cache. And IOAT will force it out of cache.
>
>
> > Additionally, current IOAT is memory->memory.  I would love to be able 
> > to convince Intel to add transforms and checksums, to enable offload of 
> > memory->transform->memory and memory->checksum->result operations like 
> > sha-{1,256} hashing[1], crc32*, aes crypto, and other highly common 
> > operations.  All of that could be made async.
>
>
> I remember the registers in the Amiga Blitter for this and I'm
> still scared... Maybe it's better to keep it simple.

We're talking about CISC here!  ;-) ;-)

[note: I'm the type of person who would stuff the kernel + glibc onto an 
FPGA, if I could]

I would love to see Intel, AMD, VIA (others?) compete by adding selected 
transforms/checksums/hashs to their chips, though this method.  Just 
provide a method to enumerate what transforms are supported on <this> 
chip...

	Jeff


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