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 2B6C3A0554; Tue, 18 Feb 2020 06:16:17 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DE1FE1D578; Tue, 18 Feb 2020 06:16:15 +0100 (CET) Received: from mail-il1-f169.google.com (mail-il1-f169.google.com [209.85.166.169]) by dpdk.org (Postfix) with ESMTP id 36D101D552 for ; Tue, 18 Feb 2020 06:16:15 +0100 (CET) Received: by mail-il1-f169.google.com with SMTP id p8so16193147iln.12 for ; Mon, 17 Feb 2020 21:16:15 -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=8gAR8x1Fgbx/oYFcCgJW1F7C62f5Ij+5qbq/aMy5G5U=; b=trHQ7ikT7waQnwNDtqjapo5YBbgsvILJqKchav7j1VdhYazcrXISZMzJme1I4XIOoQ CflVhfAJRwVgROFcUQMK8QPf+pZbtzQVhqEQlxWR06xZ+d/2E1dnwC1bJBSdMXRNxMo3 SlSkymDMVr3xfzVj/Q4jIv2GY+Syd2KkTmVrHupEaXPpYkOF/XmlFAmZdTEBOoo88fWN /367yDYzR76hEi5c9YwseK6uIr4J0qZ2rJI5DY12HY1ptANNYU1D07cMfJ8PDLO8ACAU YWLnpIM63iPTMefxDN6bkGMlGTGIBMigHqeJfNvOatTHOR+yN/N7vYozrkwWRCpW60H9 VQlw== 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=8gAR8x1Fgbx/oYFcCgJW1F7C62f5Ij+5qbq/aMy5G5U=; b=ZNN4lQv0W9h4upT1+uVu5ZZ+205gz80RNJBviyNHu+KO6UCvS9LHKzeLYcVEyJm1MW TdURt6YF+f+M3STARR+SJQxPDcN4dFTs2QsTAcWEXlb9iwxSHDamo7VzXI/dtwthhlsT DvYudnoRLP3n6qCcDwUy15mQGouKoCLnawKKQPYrV1sp9RemmBfRQ6WK6IFceDv0W62E H7J1C0EgucJ3CGJROZOeug89kK3AIdj0ChibThXXDaXy9AzTylPcBSvAEWzsMOuXKGY0 ezsdjIpPrBpg7nexhJjIiLqM11tEIgyreFkQ5bl2S5PMzTvb4WMkvNiAJXoqLSnm9vb9 qHnQ== X-Gm-Message-State: APjAAAXPt0i1YtnzSATl2GvBlhvqjjFMrNR5XEbHz8LC6PqW8oYVaX8o Je6eq+0dIii4ZLsARmhOKf6oQUjI65Zp9nqDtz3ecVGKFSU= X-Google-Smtp-Source: APXvYqx4j5QFbwITScZyEIDbKqp4LESrmwtyimitJXRPXsPCsFUyJEM0WGQVFb07hJBLNoZkR9aFN2u2ctPFlwbO+qM= X-Received: by 2002:a92:481d:: with SMTP id v29mr17679618ila.271.1582002974475; Mon, 17 Feb 2020 21:16:14 -0800 (PST) MIME-Version: 1.0 References: <1580827512-178449-1-git-send-email-david.coyle@intel.com> In-Reply-To: From: Jerin Jacob Date: Tue, 18 Feb 2020 10:45:58 +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:20 PM Doherty, Declan wrote: > > On 07/02/2020 2:18 PM, 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. > > > > The case we were looking at is more focused on a single discrete > (multi-function) device (from the perspective of the host) providing a > number of transforms (operations) in a single pass rather than the case > of N discrete hardware devices (from the perspective of the host) > chained together to achieve the same transforms set. Yes. For multifunction PCI device, it will be easy as it has a single DMA stream aka single IOMMU context. DMA between Two discrete hardware devices may need additional semantics. > > > > 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. > > >