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 7AA4FA0542; Sat, 8 Feb 2020 08:23:15 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C1F621BFC4; Sat, 8 Feb 2020 08:23:14 +0100 (CET) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) by dpdk.org (Postfix) with ESMTP id 6AFBA1BFAB for ; Sat, 8 Feb 2020 08:23:13 +0100 (CET) Received: by mail-io1-f50.google.com with SMTP id z193so2126187iof.1 for ; Fri, 07 Feb 2020 23:23:13 -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=V+qRYfAAeeMce9eoTYudgi50i9niW/rq84G7r3cLxOA=; b=QzEwzRXo8ponJmARDpih+kx3gRHpI3CZpxF6MVGmevoYZ58Ggheq6Q9ssKmIxvqjaC 1+LbQpa3ok52VvRClQICYPjGFZFAg7+dwtfl67r14xm7sYx6C50C7fromWcU11rxefSW GlxRYeMppjYM4Je7kjr/o5QlrE8Tbkih4T2qW4bZmSLdp9qp2WPxVmbYKPpzg84qkqx/ hr70DIfeYzIEfDWCT89mA9sXWthiZ+KsksUOEpqmtmGmO04FeKw0wNiGic7Y+IzhxU4H YqQYnU5xo5X3vS+fjXcINf3TynVc7HFxvoyXsq/c6S8585jT3KkS7y4jnTRMbxAmgiC8 9WHA== 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=V+qRYfAAeeMce9eoTYudgi50i9niW/rq84G7r3cLxOA=; b=iZh4NFUWzroxU5LBETogFvQzg65MJ3RTXNfF1tZzLRqjVuF+fV8MszyjB9OVUKTNPU HDvBjR0JPCa/sdR3bhwRP3lVT/6QjTFJ4gpzBujOgmzdzOzy1N5tP9haBIW6gJjjuGyb 1VocwKhmfTeyUJQfZm51roqqef5eZf12tyLe/cccx7oulrtHaJnTBgoVDZVDw7MVSU1c vzyHoz+KHpV4GAO9dLD7r8u3Ay3Zi9nnnlR5v4dunsGTg/GjITfq03dWf6Q/fWU3Xl/x 8+CwhzzH0DEfTV5TWIEiS3HSrhVUyWCvxTixB2WsFOVEEYJPlcUoGSjMVMXz+6/Wm6QO dIlg== X-Gm-Message-State: APjAAAUZFD7KtaD9hK6+yTASoPvlUHESPEzxu0Baarm19G9MlFlRV/MY zz27EOBIYYGGb/Egpx47XCpALGyIVntfnOegERHAgY4cx+g= X-Google-Smtp-Source: APXvYqxZnxjJwfMD/zB9JUZih0gGgAcXkqGmy0GByH5TUXq3zB1eOqI5+1aUPaLeDpIu75e3O+XXJ/+IpcZpP6rsfYg= X-Received: by 2002:a5e:8e4d:: with SMTP id r13mr1763915ioo.60.1581146592437; Fri, 07 Feb 2020 23:23:12 -0800 (PST) MIME-Version: 1.0 References: <1580827512-178449-1-git-send-email-david.coyle@intel.com> <20200207123400.7548f1e2@hermes.lan> In-Reply-To: <20200207123400.7548f1e2@hermes.lan> From: Jerin Jacob Date: Sat, 8 Feb 2020 12:52:56 +0530 Message-ID: To: Stephen Hemminger Cc: "Coyle, David" , dpdk-dev , "Doherty, Declan" , "Trahe, Fiona" , Prasun Kapoor 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 Sat, Feb 8, 2020 at 2:04 AM Stephen Hemminger wrote: > > On Fri, 7 Feb 2020 19:48:17 +0530 > Jerin Jacob wrote: > > > On Fri, Feb 7, 2020 at 6:08 PM Coyle, David wrote: > > > > > > Hi Jerin, see below > > > > Hi David, > > > > > > > > > > On Thu, Feb 6, 2020 at 10:01 PM Coyle, David > > > > wrote: > > > > > > > > > > > > > > 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) > > > > > > [DC] I understand what you are saying about the overhead of emulating the "sw queue" but this same model is already used in many of the existing device PMDs. > > > In the case of SW devices, such as AESNI-MB or NULL for crypto or zlib for compression, the enqueue/dequeue in the PMD is emulated through an rte_ring which is very efficient. > > > The accelerator API will use the existing device PMDs so keeping the same model seems like a sensible approach. > > > > In this release, we added CPU crypto support in cryptodev to support > > the synchronous model to fix the overhead. > > > > > > > > From an application's point of view, this abstraction of the underlying device type is important for usability and maintainability - the application doesn't need to know > > > the device type as such and therefore doesn't need to make different API calls. > > > > > > The enqueue/dequeue type API was also used with QAT in mind. While QAT HW doesn't support these xform chains at the moment, it could potentially do so in the future. > > > As a side note, as part of the work of adding the accelerator API, the QAT PMD will be updated to support the DOCSIS Crypto-CRC accelerator xform chain, where the Crypto > > > is done on QAT HW and the CRC will be done in SW, most likely through a call to the optimized rte_net_crc library. This will give a consistent API for the DOCSIS-MAC data-plane > > > pipeline prototype we have developed, which uses both AESNI-MB and QAT for benchmarks. > > > > > > We will take your feedback on the enqueue/dequeue approach for SW devices into consideration though during development. > > > > > > Finally, I'm unsure what you mean by this line: > > > > > > "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)" > > > > > > What do mean by different HW working "hand in hand" and "two PCI device"? > > > The intention is that 1 HW device (or it's PMD) would have to support the accel xform chain > > > > I was thinking, it will be N PCIe devices that create the chain. Each > > distinct PCI device does the fixed-function and chains them together. > > > > I do understand the usage of QAT HW and CRC in SW. > > So If I understand it correctly, in rte_security, we are combining > > rte_ethdev and rte_cryptodev. With this spec, we are trying to > > combine, > > rte_cryptodev and rte_compressdev. So it looks good to me. My only > > remaining concern is the name of this API, accelerator too generic > > name. IMO, like rte_security, we may need to give more meaningful name > > for the use case where crytodev and compressdev can work together. > > Having an API that could be used by parallel hardware does make sense, > but the DPDK already has multiple packet processing infrastructure pieces. > > I would rather the DPDK converge on one widely used, robust and tested packet > method. Rather than the current "choose your poison or roll your own" which is > what we have now. The proposed graph seems to be the best so far. I agree. Even I thought of saying graph can do this, as, it has higher abstraction and runtime chaining support, but then I thought it will be self markering. David could you check https://www.mail-archive.com/dev@dpdk.org/msg156318.html If this one only focusing crypto dev + compressdev, What if we have ethdev + compressdev + security device in the future. graph has higher abstraction so it can accommodate ANY chaining requirements. i.e AESNI-MB + QAT will go as a separate node