On Tue, Feb 7, 2017 at 11:46 PM, Dan Williams <[email protected]> wrote: > On Tue, Feb 7, 2017 at 1:02 AM, Anup Patel <[email protected]> wrote: >> On Tue, Feb 7, 2017 at 1:57 PM, Dan Williams <[email protected]> >> wrote: >>> On Tue, Feb 7, 2017 at 12:16 AM, Anup Patel <[email protected]> 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 <[email protected]> >>>> Reviewed-by: Scott Branden <[email protected]> >>> >>> 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 Regards, Anup
