From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Williams Subject: Re: [PATCH v2 2/5] async_tx: Handle DMA devices having support for fewer PQ coefficients Date: Thu, 9 Feb 2017 08:44:02 -0800 Message-ID: References: <1486455406-11202-1-git-send-email-anup.patel@broadcom.com> <1486455406-11202-3-git-send-email-anup.patel@broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Vinod Koul , Rob Herring , Mark Rutland , Herbert Xu , "David S . Miller" , Jassi Brar , Ray Jui , Scott Branden , Jon Mason , Rob Rice , BCM Kernel Feedback , "dmaengine@vger.kernel.org" , Device Tree , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , linux-crypto@vger.kernel.org, linux-raid To: Anup Patel Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-crypto.vger.kernel.org On Thu, Feb 9, 2017 at 1:29 AM, Anup Patel wrote: > On Wed, Feb 8, 2017 at 9:54 PM, Dan Williams wrote: >> On Wed, Feb 8, 2017 at 12:57 AM, Anup Patel wrote: >>> On Tue, Feb 7, 2017 at 11:46 PM, Dan Williams wrote: >>>> On Tue, Feb 7, 2017 at 1:02 AM, Anup Patel wrote: >>>>> On Tue, Feb 7, 2017 at 1:57 PM, Dan Williams wrote: >>>>>> On Tue, Feb 7, 2017 at 12:16 AM, Anup Patel wrote: >>>>>>> The DMAENGINE framework assumes that if PQ offload is supported by a >>>>>>> DMA device then all 256 PQ coefficients are supported. This assumption >>>>>>> does not hold anymore because we now have BCM-SBA-RAID offload engine >>>>>>> which supports PQ offload with limited number of PQ coefficients. >>>>>>> >>>>>>> This patch extends async_tx APIs to handle DMA devices with support >>>>>>> for fewer PQ coefficients. >>>>>>> >>>>>>> Signed-off-by: Anup Patel >>>>>>> Reviewed-by: Scott Branden >>>>>> >>>>>> I don't like this approach. Define an interface for md to query the >>>>>> offload engine once at the beginning of time. We should not be adding >>>>>> any new extensions to async_tx. >>>>> >>>>> Even if we do capability checks in Linux MD, we still need a way >>>>> for DMAENGINE drivers to advertise number of PQ coefficients >>>>> handled by the HW. >>>>> >>>>> I agree capability checks should be done once in Linux MD but I don't >>>>> see why this has to be part of BCM-SBA-RAID driver patches. We need >>>>> separate patchsets to address limitations of async_tx framework. >>>> >>>> Right, separate enabling before we pile on new hardware support to a >>>> known broken framework. >>> >>> Linux Async Tx not broken framework. The issue is: >>> 1. Its not complete enough >>> 2. Its not optimized for very high through-put offload engines >> >> I'm not understanding your point. I'm nak'ing this change to add yet >> more per-transaction capability checking to async_tx. I don't like the >> DMA_HAS_FEWER_PQ_COEF flag, especially since it is equal to >> DMA_HAS_PQ_CONTINUE. I'm not asking for all of async_tx's problems to >> be fixed before this new hardware support, I'm simply saying we should >> start the process of moving offload-engine capability checking to the >> raid code. > > The DMA_HAS_FEWER_PQ_COEF is not equal to > DMA_HAS_PQ_CONTINUE. #define DMA_HAS_PQ_CONTINUE (1 << 15 #define DMA_HAS_FEWER_PQ_COEF (1 << 15) > I will try to drop this patch and take care of unsupported PQ > coefficients in BCM-SBA-RAID driver itself even if this means > doing some computations in BCM-SBA-RAID driver itself. That should be nak'd as well, please do capability detection in a routine that is common to all raid engines. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753191AbdBIQpG (ORCPT ); Thu, 9 Feb 2017 11:45:06 -0500 Received: from mail-ot0-f177.google.com ([74.125.82.177]:33736 "EHLO mail-ot0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752688AbdBIQpA (ORCPT ); Thu, 9 Feb 2017 11:45:00 -0500 MIME-Version: 1.0 In-Reply-To: References: <1486455406-11202-1-git-send-email-anup.patel@broadcom.com> <1486455406-11202-3-git-send-email-anup.patel@broadcom.com> From: Dan Williams Date: Thu, 9 Feb 2017 08:44:02 -0800 Message-ID: Subject: Re: [PATCH v2 2/5] async_tx: Handle DMA devices having support for fewer PQ coefficients To: Anup Patel Cc: Vinod Koul , Rob Herring , Mark Rutland , Herbert Xu , "David S . Miller" , Jassi Brar , Ray Jui , Scott Branden , Jon Mason , Rob Rice , BCM Kernel Feedback , "dmaengine@vger.kernel.org" , Device Tree , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , linux-crypto@vger.kernel.org, linux-raid Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 9, 2017 at 1:29 AM, Anup Patel wrote: > On Wed, Feb 8, 2017 at 9:54 PM, Dan Williams wrote: >> On Wed, Feb 8, 2017 at 12:57 AM, Anup Patel wrote: >>> On Tue, Feb 7, 2017 at 11:46 PM, Dan Williams wrote: >>>> On Tue, Feb 7, 2017 at 1:02 AM, Anup Patel wrote: >>>>> On Tue, Feb 7, 2017 at 1:57 PM, Dan Williams wrote: >>>>>> On Tue, Feb 7, 2017 at 12:16 AM, Anup Patel wrote: >>>>>>> The DMAENGINE framework assumes that if PQ offload is supported by a >>>>>>> DMA device then all 256 PQ coefficients are supported. This assumption >>>>>>> does not hold anymore because we now have BCM-SBA-RAID offload engine >>>>>>> which supports PQ offload with limited number of PQ coefficients. >>>>>>> >>>>>>> This patch extends async_tx APIs to handle DMA devices with support >>>>>>> for fewer PQ coefficients. >>>>>>> >>>>>>> Signed-off-by: Anup Patel >>>>>>> Reviewed-by: Scott Branden >>>>>> >>>>>> I don't like this approach. Define an interface for md to query the >>>>>> offload engine once at the beginning of time. We should not be adding >>>>>> any new extensions to async_tx. >>>>> >>>>> Even if we do capability checks in Linux MD, we still need a way >>>>> for DMAENGINE drivers to advertise number of PQ coefficients >>>>> handled by the HW. >>>>> >>>>> I agree capability checks should be done once in Linux MD but I don't >>>>> see why this has to be part of BCM-SBA-RAID driver patches. We need >>>>> separate patchsets to address limitations of async_tx framework. >>>> >>>> Right, separate enabling before we pile on new hardware support to a >>>> known broken framework. >>> >>> Linux Async Tx not broken framework. The issue is: >>> 1. Its not complete enough >>> 2. Its not optimized for very high through-put offload engines >> >> I'm not understanding your point. I'm nak'ing this change to add yet >> more per-transaction capability checking to async_tx. I don't like the >> DMA_HAS_FEWER_PQ_COEF flag, especially since it is equal to >> DMA_HAS_PQ_CONTINUE. I'm not asking for all of async_tx's problems to >> be fixed before this new hardware support, I'm simply saying we should >> start the process of moving offload-engine capability checking to the >> raid code. > > The DMA_HAS_FEWER_PQ_COEF is not equal to > DMA_HAS_PQ_CONTINUE. #define DMA_HAS_PQ_CONTINUE (1 << 15 #define DMA_HAS_FEWER_PQ_COEF (1 << 15) > I will try to drop this patch and take care of unsupported PQ > coefficients in BCM-SBA-RAID driver itself even if this means > doing some computations in BCM-SBA-RAID driver itself. That should be nak'd as well, please do capability detection in a routine that is common to all raid engines. From mboxrd@z Thu Jan 1 00:00:00 1970 From: dan.j.williams@intel.com (Dan Williams) Date: Thu, 9 Feb 2017 08:44:02 -0800 Subject: [PATCH v2 2/5] async_tx: Handle DMA devices having support for fewer PQ coefficients In-Reply-To: References: <1486455406-11202-1-git-send-email-anup.patel@broadcom.com> <1486455406-11202-3-git-send-email-anup.patel@broadcom.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Feb 9, 2017 at 1:29 AM, Anup Patel wrote: > On Wed, Feb 8, 2017 at 9:54 PM, Dan Williams wrote: >> On Wed, Feb 8, 2017 at 12:57 AM, Anup Patel wrote: >>> On Tue, Feb 7, 2017 at 11:46 PM, Dan Williams wrote: >>>> On Tue, Feb 7, 2017 at 1:02 AM, Anup Patel wrote: >>>>> On Tue, Feb 7, 2017 at 1:57 PM, Dan Williams wrote: >>>>>> On Tue, Feb 7, 2017 at 12:16 AM, Anup Patel wrote: >>>>>>> The DMAENGINE framework assumes that if PQ offload is supported by a >>>>>>> DMA device then all 256 PQ coefficients are supported. This assumption >>>>>>> does not hold anymore because we now have BCM-SBA-RAID offload engine >>>>>>> which supports PQ offload with limited number of PQ coefficients. >>>>>>> >>>>>>> This patch extends async_tx APIs to handle DMA devices with support >>>>>>> for fewer PQ coefficients. >>>>>>> >>>>>>> Signed-off-by: Anup Patel >>>>>>> Reviewed-by: Scott Branden >>>>>> >>>>>> I don't like this approach. Define an interface for md to query the >>>>>> offload engine once at the beginning of time. We should not be adding >>>>>> any new extensions to async_tx. >>>>> >>>>> Even if we do capability checks in Linux MD, we still need a way >>>>> for DMAENGINE drivers to advertise number of PQ coefficients >>>>> handled by the HW. >>>>> >>>>> I agree capability checks should be done once in Linux MD but I don't >>>>> see why this has to be part of BCM-SBA-RAID driver patches. We need >>>>> separate patchsets to address limitations of async_tx framework. >>>> >>>> Right, separate enabling before we pile on new hardware support to a >>>> known broken framework. >>> >>> Linux Async Tx not broken framework. The issue is: >>> 1. Its not complete enough >>> 2. Its not optimized for very high through-put offload engines >> >> I'm not understanding your point. I'm nak'ing this change to add yet >> more per-transaction capability checking to async_tx. I don't like the >> DMA_HAS_FEWER_PQ_COEF flag, especially since it is equal to >> DMA_HAS_PQ_CONTINUE. I'm not asking for all of async_tx's problems to >> be fixed before this new hardware support, I'm simply saying we should >> start the process of moving offload-engine capability checking to the >> raid code. > > The DMA_HAS_FEWER_PQ_COEF is not equal to > DMA_HAS_PQ_CONTINUE. #define DMA_HAS_PQ_CONTINUE (1 << 15 #define DMA_HAS_FEWER_PQ_COEF (1 << 15) > I will try to drop this patch and take care of unsupported PQ > coefficients in BCM-SBA-RAID driver itself even if this means > doing some computations in BCM-SBA-RAID driver itself. That should be nak'd as well, please do capability detection in a routine that is common to all raid engines.