From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2B840A0552; Tue, 18 Feb 2020 06:31:19 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1CB081DA0A; Tue, 18 Feb 2020 06:31:18 +0100 (CET) Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) by dpdk.org (Postfix) with ESMTP id A86EF1D8CC for ; Tue, 18 Feb 2020 06:31:16 +0100 (CET) Received: by mail-io1-f65.google.com with SMTP id x1so9491213iop.7 for ; Mon, 17 Feb 2020 21:31:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=92ev3JSdxCL3ff+1XQvQBPeTSKCzsPC2VzenS9ZJeNU=; b=BozBd8+jKXi3ylb9zUPHE2EDtfNu5oPnu7WWNlYJWZI57gE7OzdamlqoY9HmldI7Iz uJTrksXTevruK3hhwLxLQVJjFnkDvgR6kN3CDitX0H4Fy5yKwLhOLnqt5JyPp63aqZDZ vkvxEYYxdvxUWsmlMV9h0oJo9noPocHU3hpVVq3K/3a06rV0kCt8e6D4gHvehGICFl8g r5ONi3v8pN+xhq/Ng2zf2wqa/KG4M40gLwZWypOrA2v6N/vYSNbW+E0+6iQvN4SQPdrm IaOaVgPyeC1PeQFIQ9xqvKJrA7gpi0DotZEs0bln+nWRRMqeWqED5UMg2twi+hs0wBIG iHvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=92ev3JSdxCL3ff+1XQvQBPeTSKCzsPC2VzenS9ZJeNU=; b=MySZLxOkqNXnIwyn9r8FXKgkxmf8ckZ44rJoLXrJ5LXYnDkmffg9Pyqe51JUjCM+HU esa8ePAhgWGkn4qY8GXTW1yrpeFYXWwjM8Mpe31b2hRbnw855o4qy9ad4e5WjCYEQTk4 LhxZcM+M8JJyGH4dSd0EmjTrtkKltlxd0jGSmfDY1Yf5h3gM4UvEqrNiuU/pyLxtXQFv FP/ly+V8IraXutWvzJOgCDq3az4sydNvEnOO2nxkhYrIwEEVxNaJeW7LeGhDZ2v/o3ZK AYTl1EyIDhlMEQSPr4c7SD36o8ko3aZtD2Og7ypPLKWeeGHF7jqDVwVQ0kAtJYVQUTtj +zTg== X-Gm-Message-State: APjAAAUcn2T2X5KnNNRhEwDgmfxFwS3+wi+YAzTik8bgRA+2FTIrAnvw uhUj4G/YfaRXz2uxwTedo5LPKXFRpmcp3tRe+hY= X-Google-Smtp-Source: APXvYqwiTY5vJWoQjOs7l9eJR+v86m5CVH6J2YDhSdz1Xs4EXrB6JsIFK9deoq2SGJr4rryc7pZi8GKr+N/la1Agg64= X-Received: by 2002:a5e:8e4d:: with SMTP id r13mr13504392ioo.60.1582003875810; Mon, 17 Feb 2020 21:31:15 -0800 (PST) MIME-Version: 1.0 References: <1580827512-178449-1-git-send-email-david.coyle@intel.com> <18fd52c0-6f44-6742-ae29-a221bf3f982b@intel.com> In-Reply-To: <18fd52c0-6f44-6742-ae29-a221bf3f982b@intel.com> From: Jerin Jacob Date: Tue, 18 Feb 2020 11:00:59 +0530 Message-ID: To: "Doherty, Declan" Cc: "Coyle, David" , dpdk-dev , "Trahe, Fiona" Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [RFC] Accelerator API to chain packet processing functions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Feb 13, 2020 at 5:14 PM Doherty, Declan wrote: > > On 06/02/2020 5:13 PM, Jerin Jacob wrote: > > On Thu, Feb 6, 2020 at 10:01 PM Coyle, David wrote: > > > > Hi David, > > > >>> > >>> > >>>>>> - XGS-PON MAC: Crypto-CRC-BIP > >>>>>> - Order: > >>>>>> - Downstream: CRC, Encrypt, BIP > >>>>> > >>>>> I understand if the chain has two operations then it may possible to > >>>>> have handcrafted SW code to do both operations in one pass. > >>>>> I understand the spec is agnostic on a number of passes it does > >>>>> require to enable the xfrom but To understand the SW/HW capability, > >>>>> In the above case, "CRC, Encrypt, BIP", It is done in one pass in SW > >>>>> or three passes in SW or one pass using HW? > >>>> > >>>> [DC] The CRC, Encrypt, BIP is also currently done as 1 pass in AESNI MB > >>> library SW. > >>>> However, this could also be performed as a single pass in a HW > >>>> accelerator > >>> > >>> As a specification, cascading the xform chains make sense. > >>> Do we have any HW that does support chaining the xforms more than "two" > >>> in one pass? > >>> i.e real chaining function where two blocks of HWs work hand in hand for > >>> chaining. > >>> If none, it may be better to abstract as synonymous API(No dequeue, no > >>> enqueue) for the CPU use case. > >> > >> [DC] I'm not aware of any HW that supports this at the moment, but that's not to say it couldn't in the future - if anyone else has any examples though, please feel free to share. > >> Regardless, I don't see why we would introduce a different API for SW devices and HW devices. > > > > There is a risk in drafting API that meant for HW without any HW > > exists. Because there could be inefficiency on the metadata and fast > > path API for both models. > > For example, In the case of CPU based scheme, it will be pure overhead > > emulate the "queue"(the enqueue and dequeue) for the sake of > > abstraction where > > CPU works better in the synchronous model and I have doubt that the > > session-based scheme will work for HW or not as both difference HW > > needs to work hand in hand(IOMMU aspects for two PCI device) > > We do have some proto-types in hardware which can do operation chaining > but in the case we have looked at, it is a single accelerator device > with multi-function which means the orchestration (order, passing of > data etc) of the chained operations is handled within the device itself, > meaning that we didn't see issues with shared session data or handling > moving data along discrete independent stage of a hardware pipeline > wasn't an issue. > > Although if you wanted to offer this type of chained offload, I think we > would need the driver to handle this for the user, rather than the > application needing to understand how the hardware pipeline is interacting. Yes. The application should not understand the specifics. The only question how to make this generic so that any hardware/SW pipeline can work. Currently, we have rte_security, which works on ethdev and cryptodev. This new spec is going to work on rte_cryptodev and rte_compressdev. If so, we need another pipeline which needs to work with rte_cryptodev, rte_compressdev and ethdev then we need to invent a new library. I agree with the need for the hardware/SW pipeline. As Stephen suggested, Why not look for general abstraction for HW/SW based pipeline. Marvell had a similar problem in abstracting various HW/SW pipeline, Here is a proposal for a generic HW/SW pipeline. http://mails.dpdk.org/archives/dev/2020-January/156765.html If the focus only for a specific case, say "CRC + something else", better to have API for that and better to not call the accelerator for the packet processing pipeline as it has a big scope. Just my 2c. > > > > > Having said that, I agree with the need for use case and API for CPU > > case. Till we find a HW spec, we need to make the solution as CPU > > specific and latter extend based on HW metadata required. > > Accelerator API sounds like HW accelerator and there is no HW support > > then it may not good. We can change the API that works for the use > > cases that we know how it works efficiently. > > > > > > > > > > > > > > > >> It would be up to each underlying PMD to decide if/how it supports a particular accelerator xform chain, but from an application's point of view, the accelerator API is always the same > >> > >> >