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 E1E32A0540; Thu, 6 Feb 2020 18:14:00 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 144461C1B9; Thu, 6 Feb 2020 18:14:00 +0100 (CET) Received: from mail-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) by dpdk.org (Postfix) with ESMTP id B7A511C1B7 for ; Thu, 6 Feb 2020 18:13:58 +0100 (CET) Received: by mail-io1-f68.google.com with SMTP id d15so7179764iog.3 for ; Thu, 06 Feb 2020 09:13:58 -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=gvErO4ELzP1KDIOq9QWBAP45dA3YQNcVLeOfHjutZgI=; b=NDGASDuIor72pk6SbtX0X/fCKyNS+f3KWRvDVJvlt4FO+vsAnZJdP2a/5qA1cqtI/t 7Ptcz1daxzrlRXrnkgg8XsPNdr8IL+nOWv28M/dhR5SActrw3YJbZ2L/gRKnYFeQvtYh RNHa7hGBsoiYkhf63TY+ks0pki8NBYP5yGJ166ptSEdWWtX2dz2d0v0uOmg1KFbP38hY Do+w+p/NS70/id2o9p/AZEGhyxxr3AWeEC0nrSPrvzzNbECG6A1oWgZPrBqgINji7u8+ /9/E/I6E2TAE8rt2BIZWDyq2sITa+IdRg8QZqaSdoz5mP9wlS3XgKzLulpckpUhVruYE iXCA== 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=gvErO4ELzP1KDIOq9QWBAP45dA3YQNcVLeOfHjutZgI=; b=H0xW7o6qj8kWshzJ2mrQGJj8glto/Whvmlit2dblhnB+07ZTSBRiRo8n/BjzymT0Zs ZfktGz9cCVFT/GimagnR2OBBmpz58pvGF6+3r0q4ihDi5TuAWFh7YSpOCb/6Tkw05iXw FGQMP0fPymMj4DCiLGkgmhcoHiBvU1JNyqsC5hLra0O+qdCSedZXwTJsJLdQgiTOgXFE kB4EhyFPXlIkUmIGrl6PoTwqpLHldnI8j0NsJxBC1G/em0pj/pBG9dSlQxbrB+mF3+cp sRVMTI5R7l6zZq2PvGwLjWmskC2LBdpNp/pDzP6srvZuFw3G2WGOG2wNArM6ugCvTx0R 8wKg== X-Gm-Message-State: APjAAAXYzBIGcIWfJ85jkqvK9S0tVC8NI4UQfaKovSmrnTuHyTD+iw3r y0ipZLypS1hPEzL3ZaFjhpZ+142MMVA66So9AHI= X-Google-Smtp-Source: APXvYqzKJyaMxdrhm/ifW/Ml4KOO40r+D014hmkr8Ay46A9uz8PRRoNjLKLknYyngE5eqp8aP9sNnCoeDihcvEpf7hs= X-Received: by 2002:a5e:8516:: with SMTP id i22mr34959559ioj.130.1581009237747; Thu, 06 Feb 2020 09:13:57 -0800 (PST) MIME-Version: 1.0 References: <1580827512-178449-1-git-send-email-david.coyle@intel.com> In-Reply-To: From: Jerin Jacob Date: Thu, 6 Feb 2020 22:43:40 +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 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) 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 > >