On Wed, Feb 15, 2017 at 06:42:09PM -0800, Dan Williams wrote: > Back in 2011, Russell pointed out that the "async_tx channel switch" > capability was violating expectations of the dma mapping api [1]. At the > time the existing uses were reviewed as still usable, but that longer > term we needed a rework of the raid offload implementation. While some > of the framework for a fixed implementation was introduced in 2012 [2], > the wider rewrite never materialized. > > There continues to be interest in raid offload with new dma/raid engine > drivers being submitted. Those drivers must not build on top of the > broken channel switching capability. > > Prevent async_tx from using an offload engine if the channel switching > capability is enabled. This still allows the engine to be used for other > purposes, but the broken way async_tx uses these engines for raid will > be disabled. For configurations where this causes a performance > regression the only solution is to start the work of eliminating the > async_tx api and moving channel management into the raid code directly > where it can manage marshalling an operation stream between multiple dma > channels. Applied, thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
