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 D3F29A0542; Fri, 7 Feb 2020 21:34:13 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BCFB21BFEB; Fri, 7 Feb 2020 21:34:12 +0100 (CET) Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) by dpdk.org (Postfix) with ESMTP id DB6392629 for ; Fri, 7 Feb 2020 21:34:10 +0100 (CET) Received: by mail-pg1-f182.google.com with SMTP id b35so343521pgm.13 for ; Fri, 07 Feb 2020 12:34:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=QgNCQC1RIwANfEyQnOScULY6PF+1zUE3em1UzQFRfX8=; b=OCA3LSZaASyRE02qpwkJ1LEO4rrXboZjwtDc/nEVICH5g2Dx0xVLbnswoZVD/i7iPx HAy160ndGPdCNr6HB7li0e/B2iF8NYnpZCwqwk1JCxcYBUEKI6kUT0pm1sB8NBVnLjox hqpK8ycDrRLVwnT3VMyWz15R1EzJ4jB+T9RKuqmraYlktkoIkrnoyMdAOTJ06qF6gHk0 UhUv9+9aKDo4JjQvDLBVDufQxcJ05+k+dhpWXd4fSG2GXMRLO11GukoOviW10CmAwy4E ffg121t5KbG+QhTMsTyklnrp/OUqrvMHrJBttLvOqNORZqITc4mHQcYBWtZvcigbl8ue VqiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=QgNCQC1RIwANfEyQnOScULY6PF+1zUE3em1UzQFRfX8=; b=mFtfjoLhv47NeiO42JnG0DQk/JQQYxNREoCbG+kZV4fcQiA0EcMfr9Gt7Hqof83adu 99BC+oOHzm/O4vU33el158CmA8PunMZe8cZzvQTpnqiif80lQH9SFhfQQ68jXRRm+NTS gAKl7qf4lYl1lY7cVH94xk4Xwe0WILnixAUPJdLMlgT/hn2sToZku/Kp+ed6GEE3vF5Y 5GYvdSl/Pm1XDj3/0TlqShEy+Uv17k+VowBieAPmqGUPKO0B3nEQuxGqdS5X1yrk3onE tq2VcvFmKV8Xo+9oI+mKvSDUUTDCdvy+AB/fk1qiHktJzd7fcdIiwP3VxcOS3kH462n3 Yiwg== X-Gm-Message-State: APjAAAVWKGLvEzOZHwh3KrzzZUeIO2SlC3pVPUdtEIC7AGNDyvmtUhsx P4GkND6ZJjNEkset1ePTkRjRPg== X-Google-Smtp-Source: APXvYqyAoo7L5BFFutVDOJSFeDiJz2WOt99vGnDrLRciBNX7Y1kONpd8haLe/Ba6BmrhWS81JQ4nRA== X-Received: by 2002:a63:a55e:: with SMTP id r30mr1013750pgu.109.1581107649777; Fri, 07 Feb 2020 12:34:09 -0800 (PST) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id u3sm3542560pjv.32.2020.02.07.12.34.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Feb 2020 12:34:09 -0800 (PST) Date: Fri, 7 Feb 2020 12:34:00 -0800 From: Stephen Hemminger To: Jerin Jacob Cc: "Coyle, David" , dpdk-dev , "Doherty, Declan" , "Trahe, Fiona" Message-ID: <20200207123400.7548f1e2@hermes.lan> In-Reply-To: References: <1580827512-178449-1-git-send-email-david.coyle@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 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.