On Jul 31, 2012, at 7:10 PM, "Jianbin Kang" <kjbmail@xxxxxxxxx> wrote: >> Actually this is what I'm working on now, using async_tx to replace the >> memcpy. I believe the changes shouldn't be that significant. >> >> Is the "hardware that can setup dma" you refer to something that does >> not use this interface? >> > > Yes, they use this interface, but split 'memcpy_toio' to two operation: > 1. setup dma > 2. wait/poll for the dma to finish. > So maybe it need to provide a generic function 'tx' for different hardwares. > It's not worth it to do sync DMA. The performance is terrible. > If async_tx is available, it's much better than this 'sync dma/memcpy'. > One problem with async_tx is, it can't detect memcpy error. > If the remote ntb goes down when async_memcpy is in operation, async_tx > will trigger an oops. Yes that is something that needs to be addressed when we get async DMA support working. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
