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 8C2DAA0542; Fri, 7 Feb 2020 15:18:37 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D2C491C114; Fri, 7 Feb 2020 15:18:36 +0100 (CET) Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) by dpdk.org (Postfix) with ESMTP id F2B271C0DB for ; Fri, 7 Feb 2020 15:18:35 +0100 (CET) Received: by mail-io1-f49.google.com with SMTP id h8so2369604iob.2 for ; Fri, 07 Feb 2020 06:18:35 -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=nEIcnd/e/cBoIKraS2cC9uQNXhshYJWIQ5b6DOq+k+Y=; b=srVeLB9Fql+tpS1hGnMjX9UZQAE8+3FwOeMNFP0jype5mI2ENuFqr9qrLvJg27F/uX gH7TLQdDmRpqjMIk2X/XSEc4XTNJW7ODtju3Q1M940IsypsXVdQOvahec+7fgaRFRnId Ezod1zhrOj/WxqWeuimaahg5jB7EjkErMRL5RgU9AzhVD+GWDNrlD09cWwM8j1Gtn7oX B8pwUoa5oB64jQsV5vhJsOetv8NoZAKFcZqTiWQRTpVhDnMBKhu3NX3U/ed2A9JTjtqS QGG3vLBdnotqU6hl+b2OrmG+gy1IoNnQ0ee0z8rrFrpcXTforhD+zD0gHzkaGxwDBmrQ eWDw== 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=nEIcnd/e/cBoIKraS2cC9uQNXhshYJWIQ5b6DOq+k+Y=; b=Z/XJazk830GrBQR0Kct1fBYpnIhOZ/fUHRqwn+PNT7EYKacc1kb7VX2qYenGYDfTHM VDg+6FpaINbrTHMf8kJ3n1A8vSkoRrDcku64QNuQgbWpFQmmiqN5MHJQG7Rccve/Ynnb V2qNrCrJFzDB+rdNAZB9JVwriCBOvZIoV+yii6mGrZUQFGC+DCxocK9i/q+3FEijoNmN HYsBxEaWmoB09iH4tUP06RP8c+cKRNwLzk9KZOrSn2tUHeUS/VNlcEprJLblrI5qf6wI feABYWiuboC2lbWzkTcWhNKd43S/xauZ/aOZqnQjehuajm3+nLwPDTQt23qoGgCFgBST NQKg== X-Gm-Message-State: APjAAAUo0gBt2wDkQyAjQWZCtEKpHBKRJVqEYkt2yA7ftJgtq4ihOX77 KEeZOpfAoFeUEGuh/EbL6v1qpILbJZCITJNGS+o= X-Google-Smtp-Source: APXvYqxvI2Murj+vitx2wuORAl8eFT5awuWWugVW/w0MFOTp67coBD9ePeBtx/0nNCjql42/p/UY+gjr8zDi1DnvqvY= X-Received: by 2002:a5e:8516:: with SMTP id i22mr3339945ioj.130.1581085114954; Fri, 07 Feb 2020 06:18:34 -0800 (PST) MIME-Version: 1.0 References: <1580827512-178449-1-git-send-email-david.coyle@intel.com> In-Reply-To: From: Jerin Jacob Date: Fri, 7 Feb 2020 19:48:17 +0530 Message-ID: To: "Coyle, David" Cc: dpdk-dev , "Doherty, Declan" , "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 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.