From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753261AbdBPEiw (ORCPT <rfc822;w@1wt.eu>);
        Wed, 15 Feb 2017 23:38:52 -0500
Received: from mga06.intel.com ([134.134.136.31]:53386 "EHLO mga06.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752162AbdBPEiu (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 15 Feb 2017 23:38:50 -0500
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.35,167,1484035200"; 
   d="scan'208";a="66395802"
Date: Thu, 16 Feb 2017 10:09:24 +0530
From: Vinod Koul <vinod.koul@intel.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
        Anup Patel <anup.patel@broadcom.com>,
        Rameshwar Prasad Sahu <rsahu@apm.com>,
        Russell King <linux@armlinux.org.uk>, linux-kernel@vger.kernel.org,
        linux-raid@vger.kernel.org, dmaengine@vger.kernel.org,
        Anatolij Gustschin <agust@denx.de>,
        Saeed Bishara <saeed.bishara@gmail.com>
Subject: Re: [PATCH] async_tx: deprecate broken support for channel switching
Message-ID: <20170216043924.GQ2843@localhost>
References: <148721292971.19343.10618932473668163270.stgit@dwillia2-desk3.amr.corp.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <148721292971.19343.10618932473668163270.stgit@dwillia2-desk3.amr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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