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 2ACC7A0542; Thu, 13 Feb 2020 12:44:45 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D8A531BF99; Thu, 13 Feb 2020 12:44:43 +0100 (CET) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 0493F1BE8E for ; Thu, 13 Feb 2020 12:44:41 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Feb 2020 03:44:40 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,436,1574150400"; d="scan'208";a="222622904" Received: from dwdohert-mobl.ger.corp.intel.com (HELO [163.33.176.237]) ([163.33.176.237]) by orsmga007.jf.intel.com with ESMTP; 13 Feb 2020 03:44:39 -0800 To: Jerin Jacob , "Coyle, David" Cc: dpdk-dev , "Trahe, Fiona" References: <1580827512-178449-1-git-send-email-david.coyle@intel.com> From: "Doherty, Declan" Message-ID: <18fd52c0-6f44-6742-ae29-a221bf3f982b@intel.com> Date: Thu, 13 Feb 2020 11:44:38 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 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. > > 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 >> >>