On Wed, Feb 8, 2017 at 12:57 AM, Anup Patel <anup.patel@xxxxxxxxxxxx> wrote: > On Tue, Feb 7, 2017 at 11:46 PM, Dan Williams <dan.j.williams@xxxxxxxxx> wrote: >> On Tue, Feb 7, 2017 at 1:02 AM, Anup Patel <anup.patel@xxxxxxxxxxxx> wrote: >>> On Tue, Feb 7, 2017 at 1:57 PM, Dan Williams <dan.j.williams@xxxxxxxxx> wrote: >>>> On Tue, Feb 7, 2017 at 12:16 AM, Anup Patel <anup.patel@xxxxxxxxxxxx> 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 <anup.patel@xxxxxxxxxxxx> >>>>> Reviewed-by: Scott Branden <scott.branden@xxxxxxxxxxxx> >>>> >>>> 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. -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
