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 A28CDA056A; Fri, 6 Mar 2020 09:43:37 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E72A61BFCD; Fri, 6 Mar 2020 09:43:36 +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 889472BA8 for ; Fri, 6 Mar 2020 09:43:35 +0100 (CET) Received: by mail-il1-f169.google.com with SMTP id j69so1309882ila.11 for ; Fri, 06 Mar 2020 00:43: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=Sbpc3gj0/KspnGEmvLHdUW2ly7TSEGS6Dh9O5Lw1QNs=; b=FXexfSRnoSG2MQfGiauRS5jtkoKZljLEl+srzJX1gSYDHli/fz1xg2OblfTFY8EMK4 LGcoYNayc0kZF/gbLAQfe9prc74Y2hCvUxGCa4ewa+KEyY7Wnl02eAkKWu4olXwvy8Pu /ZQv2Zi5X3bPrDibRHTG/yrgqW9eJC7jLZZtpIJaQLIRRKLojKsr+Ha/yYWDEjNBA9Z8 SgFc+lKzxpmJNTRNlkWVS7wUV0QKtRv3AdjIjvYRDd7ijNokk9om32MAN/1FH/Oe2NCl XNxxmV0W1SpP38Zp4zaSh9XW9pXoL6b+pkFYLMeaRIou2Lw0sUdrc2FcRmi7i1/Zh2cq iMTQ== 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=Sbpc3gj0/KspnGEmvLHdUW2ly7TSEGS6Dh9O5Lw1QNs=; b=OBKKdvkMkgyCFH2diDjJxzypCj8CdNipQjv7cvVKpnKk0cfJzJ6Q+uMxKSlYC2RoU1 zoTU1yPLt/haw1f1PUCnrjlTQ5TnFRsJ6OecSblasDoisyl8m/UEIZwtXn4wX11TU902 05IQnahcQejI6+UzQG249d5WQHWGSy13d+eYx2PPpLpBAAZni7EY0OnH/YKYNbjGD4XW 2LfkAgwdwFo6IYUo989Fn+aTp0WVT7yysRAWjz7DwolCamUDm43b9/rbhzYD7cIefP08 RD0RFkyVvOwTU6DDxUofSEX8CeHgPwXglpGJvC3BjKwzsLYZZ6uPbw8wJ4lKZ8yrDHMC PIWw== X-Gm-Message-State: ANhLgQ3HwfEvfhwht/TWGLk976HujJ0EXVD3bjyrazFGis7536/MQj/a m6PN8fldutaxmGgl80tnnzf418Ixx/5aGfG8jn4= X-Google-Smtp-Source: ADFU+vu1aaQ4daE/NHsAKrcsFGzH6KgO9wvHJxKaer0eA7vbG61VftQ+DoyRbnbPoo7zEnaW+G921fD9260QvSXAoqc= X-Received: by 2002:a92:d4c8:: with SMTP id o8mr2209016ilm.162.1583484214705; Fri, 06 Mar 2020 00:43:34 -0800 (PST) MIME-Version: 1.0 References: <1580827512-178449-1-git-send-email-david.coyle@intel.com> <20200207123400.7548f1e2@hermes.lan> In-Reply-To: From: Jerin Jacob Date: Fri, 6 Mar 2020 14:13:18 +0530 Message-ID: To: "Coyle, David" Cc: Stephen Hemminger , 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 Thu, Mar 5, 2020 at 10:32 PM Coyle, David wrote: > > > > > > > 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 > > [DC] We have looked at the graph node library and we don't feel that using graph is the correct solution for what we are trying to solve here. > We want to combine 2 or more packet processing functions on a packet into a single operation on a single device, be that an optimized software library such as AESNI MB or a hardware accelerator such as QAT > So yes, these 2 packet processing functions could be a node (or nodes) within a graph. > However they would still need to be combined together at some point to be processed on the device as a single operation. It is possible with graph architecture where, when application gives two nodes and they are connected then it will be possible to replace to an optimized node at runtime. Having said that, It is NOT good to dedicate the graph as THE MODEL for pipeline. i,e user should need to get both options rather sticking to one model. In that way, it makes sense to not abstract as a graph. > > Our new proposal is to use rte_rawdev to access the devices and we propose to add a "multi-function" interface which the application and rawdev PMDs will use to create the xform chains, sessions and op chains. > The full details on this new proposal have been sent to you in a separate post and we feel it addresses the concerns of the original rte_accelerator API > > In the future, rawdev enqueue/dequeue calls using this multi-function interface could potentially be configured as a node within a packet processing graph Yes. Makes sense. >