From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 872F0A0C45; Wed, 20 Oct 2021 07:26:25 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 42B8B40150; Wed, 20 Oct 2021 07:26:25 +0200 (CEST) Received: from mail-il1-f177.google.com (mail-il1-f177.google.com [209.85.166.177]) by mails.dpdk.org (Postfix) with ESMTP id 834E340142 for <dev@dpdk.org>; Wed, 20 Oct 2021 07:26:24 +0200 (CEST) Received: by mail-il1-f177.google.com with SMTP id g2so20833015ild.1 for <dev@dpdk.org>; Tue, 19 Oct 2021 22:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k5RA6NEXeizOwJBU0VwEV6KIp9VV5HB+/qJiwGWPzFM=; b=VMNcxEOqOffhJ8By8FnE7KEpoc2n6qHE16uS5DTTvKRmOQNbYrGwcy4IkXHPju08zm cqFToPVLpWWwOXeAVdSwO4bUhSr2jxJt3UKSkHTRte3IGOoBdjSAhb6kCLZsbSTjx2Sg sAjKT+SMMmP8hx3YtdRPti0nzjveB0Q4vRWpIaay9+hrokJYYwgWnVYYKUhkuDIrH8UF Idvj9ENfL9H0wPOYATwzc3CJ+t1WdEU58vdmdanU8t1lAUBA/sJagDe2jW7l/fLD5MZI 8SrIDoiYkzJ6jtRfdtb/KLwqKTu53285YDWseNrZ+gkr2jibeXfPil5FDJnqcUEbBjVK F6dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k5RA6NEXeizOwJBU0VwEV6KIp9VV5HB+/qJiwGWPzFM=; b=RZVPp5dqix3OfefkTP7+KfHr8wTRU57gqA94v1XDV3MKl6mGlWXAAgN7F/Eur5Atak 7hYq7WR0f+iKsVPbkGYENu5Lk1G7OSEBu4s5yt1w9qLuQZ7zL7wWsMtd3vaNz2zKpzoY YdqJUD7HGRkm3nUsKm0rcaiuP/i1N4TJhBlm4Bs0XjQbslRpOUJ41sbZy9ifI5X8nPAT Zj1koP/mbXbWvR/eOtTm74Yy6AUxVy846Z0yEWhFHN7FtvagDfhFr01mf01s8neBjFPm Pnbpz6fxSQ+SZG5MnBhEVg+E+ub6yQPuIGiuhEeuyREwCLO4PR2fzZ8B4aQVbfsLnTLW 5wOQ== X-Gm-Message-State: AOAM530f71yK+DXyNNDJm4dRQ6wOWXCwHewKRSueD4QyA8po9Nvtxk1v nUEdjAMsMegZb/PNtDfmvfUWlPufUU6EPdyD0ug= X-Google-Smtp-Source: ABdhPJzSU/Gv3hxmAOwfGI1m4ZcH8HewkyjaXnLd1K06SNCFpjJ6FnpaLbSXBblwxLapf5ImkaH5CtEK5TWnI8cGtic= X-Received: by 2002:a05:6e02:1d8d:: with SMTP id h13mr20328418ila.94.1634707583770; Tue, 19 Oct 2021 22:26:23 -0700 (PDT) MIME-Version: 1.0 References: <20211019181459.1709976-1-jerinj@marvell.com> <6870595.fqHcUuC4to@thomas> <CALBAE1OnC=4w=adjVjGVEKRfefo77vjOM8eUmmxza6EzEOJM0A@mail.gmail.com> <20211019134200.50322420@hermes.local> In-Reply-To: <20211019134200.50322420@hermes.local> From: Jerin Jacob <jerinjacobk@gmail.com> Date: Wed, 20 Oct 2021 10:55:57 +0530 Message-ID: <CALBAE1MSVunLK3L5dctpD=F+wCEbN=OpM07Br=sz6U8UuU-PyQ@mail.gmail.com> To: Stephen Hemminger <stephen@networkplumber.org> Cc: Thomas Monjalon <thomas@monjalon.net>, Jerin Jacob <jerinj@marvell.com>, dpdk-dev <dev@dpdk.org>, Ferruh Yigit <ferruh.yigit@intel.com>, Ajit Khaparde <ajit.khaparde@broadcom.com>, Andrew Boyer <aboyer@pensando.io>, Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>, Beilei Xing <beilei.xing@intel.com>, "Richardson, Bruce" <bruce.richardson@intel.com>, Chas Williams <chas3@att.com>, "Xia, Chenbo" <chenbo.xia@intel.com>, Ciara Loftus <ciara.loftus@intel.com>, Devendra Singh Rawat <dsinghrawat@marvell.com>, Ed Czeck <ed.czeck@atomicrules.com>, Evgeny Schemeilin <evgenys@amazon.com>, Gaetan Rivet <grive@u256.net>, Gagandeep Singh <g.singh@nxp.com>, Guoyang Zhou <zhouguoyang@huawei.com>, Haiyue Wang <haiyue.wang@intel.com>, Harman Kalra <hkalra@marvell.com>, heinrich.kuhn@corigine.com, Hemant Agrawal <hemant.agrawal@nxp.com>, Hyong Youb Kim <hyonkim@cisco.com>, Igor Chauskin <igorch@amazon.com>, Igor Russkikh <irusskikh@marvell.com>, Jakub Grajciar <jgrajcia@cisco.com>, Jasvinder Singh <jasvinder.singh@intel.com>, Jian Wang <jianwang@trustnetic.com>, Jiawen Wu <jiawenwu@trustnetic.com>, Jingjing Wu <jingjing.wu@intel.com>, John Daley <johndale@cisco.com>, John Miller <john.miller@atomicrules.com>, "John W. Linville" <linville@tuxdriver.com>, "Wiles, Keith" <keith.wiles@intel.com>, Kiran Kumar K <kirankumark@marvell.com>, Lijun Ou <oulijun@huawei.com>, Liron Himi <lironh@marvell.com>, Long Li <longli@microsoft.com>, Marcin Wojtas <mw@semihalf.com>, Martin Spinler <spinler@cesnet.cz>, Matan Azrad <matan@nvidia.com>, Matt Peters <matt.peters@windriver.com>, Maxime Coquelin <maxime.coquelin@redhat.com>, Michal Krawczyk <mk@semihalf.com>, "Min Hu (Connor" <humin29@huawei.com>, Pradeep Kumar Nalla <pnalla@marvell.com>, Nithin Dabilpuram <ndabilpuram@marvell.com>, Qiming Yang <qiming.yang@intel.com>, Qi Zhang <qi.z.zhang@intel.com>, Radha Mohan Chintakuntla <radhac@marvell.com>, Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>, Rasesh Mody <rmody@marvell.com>, Rosen Xu <rosen.xu@intel.com>, Sachin Saxena <sachin.saxena@oss.nxp.com>, Satha Koteswara Rao Kottidi <skoteshwar@marvell.com>, Shahed Shaikh <shshaikh@marvell.com>, Shai Brandes <shaibran@amazon.com>, Shepard Siegel <shepard.siegel@atomicrules.com>, Somalapuram Amaranath <asomalap@amd.com>, Somnath Kotur <somnath.kotur@broadcom.com>, Stephen Hemminger <sthemmin@microsoft.com>, Steven Webster <steven.webster@windriver.com>, Sunil Kumar Kori <skori@marvell.com>, Tetsuya Mukawa <mtetsuyah@gmail.com>, Veerasenareddy Burru <vburru@marvell.com>, Viacheslav Ovsiienko <viacheslavo@nvidia.com>, Xiao Wang <xiao.w.wang@intel.com>, Xiaoyun Wang <cloud.wangxiaoyun@huawei.com>, Yisen Zhuang <yisen.zhuang@huawei.com>, Yong Wang <yongwang@vmware.com>, Ziyang Xuan <xuanziyang2@huawei.com>, Prasun Kapoor <pkapoor@marvell.com>, nadavh@marvell.com, Satananda Burla <sburla@marvell.com>, Narayana Prasad <pathreya@marvell.com>, Akhil Goyal <gakhil@marvell.com>, Ray Kinsella <mdr@ashroe.eu>, Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>, Anatoly Burakov <anatoly.burakov@intel.com>, Cristian Dumitrescu <cristian.dumitrescu@intel.com>, Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>, =?UTF-8?Q?Mattias_R=C3=B6nnblom?= <mattias.ronnblom@ericsson.com>, "Ruifeng Wang (Arm Technology China)" <ruifeng.wang@arm.com>, David Christensen <drc@linux.vnet.ibm.com>, "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, Olivier Matz <olivier.matz@6wind.com>, "Jayatheerthan, Jay" <jay.jayatheerthan@intel.com>, Ashwin Sekhar Thalakalath Kottilveetil <asekhar@marvell.com>, Pavan Nikhilesh <pbhagavatula@marvell.com>, Elena Agostini <eagostini@nvidia.com>, David Marchand <david.marchand@redhat.com>, Tom Herbert <tom@herbertland.com> Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [RFC PATCH 0/1] Dataplane Workload Accelerator library X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> On Wed, Oct 20, 2021 at 2:12 AM Stephen Hemminger <stephen@networkplumber.org> wrote: > > On Wed, 20 Oct 2021 01:06:10 +0530 > Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > On Wed, Oct 20, 2021 at 12:38 AM Thomas Monjalon <thomas@monjalon.net> wrote: > > > > > > 19/10/2021 20:14, jerinj@marvell.com: > > > > Definition of Dataplane Workload Accelerator > > > > -------------------------------------------- > > > > Dataplane Workload Accelerator(DWA) typically contains a set of CPUs, > > > > Network controllers and programmable data acceleration engines for > > > > packet processing, cryptography, regex engines, baseband processing, etc. > > > > This allows DWA to offload compute/packet processing/baseband/ > > > > cryptography-related workload from the host CPU to save the cost and power. > > > > Also to enable scaling the workload by adding DWAs to the Host CPU as needed. > > > > > > > > Unlike other devices in DPDK, the DWA device is not fixed-function > > > > due to the fact that it has CPUs and programmable HW accelerators. > > > > This enables DWA personality/workload to be completely programmable. > > > > Typical examples of DWA offloads are Flow/Session management, > > > > Virtual switch, TLS offload, IPsec offload, l3fwd offload, etc. > > > > > > If I understand well, the idea is to abstract the offload > > > of some stack layers in the hardware. > > > > Yes. It may not just HW, For expressing the complicated workloads > > may need CPU and/or other HW accelerators. > > > > > I am not sure we should give an API for such stack layers in DPDK. > > > > Why not > This is the problem of should DPDK reinvent higher protocol layers? > Given the myriad of other projects using DPDK that already provide these > protocols; the de facto decision has been to not add higher layers. > > The boundary between DPDK and OVS, VPP, yastack, ... has stayed roughly > the same for several years. If DPDK starts to overlap these other projects > it makes life harder. The intention is to NOT replace these projects, instead, the intention is to use these projects in the accelerator. There is a subtle difference between defining the workload vs implementing the workload. This RFC attempts the former. I am trying to address the use case where the end-user needs to offload a workload to the accelerator, which contains a set of CPUs, Network controllers and programmable data acceleration engines for packet processing, cryptography, regex engines, baseband processing, etc. Offload is expressed in very high-level TLV messages. Accelerator picks these messages, and using the above technologies to implement it in acceleration HW. This enables offloading the workloads from the Host CPU. There are discrete attempts to solve this problem in isolation like https://github.com/att/sessionOffload. If you see the above workload the application cares for very high-level messages for AddSession, DeleteSession, GetSession, SendStats etc and leave the accelerator for _implementing_ those workloads. In order to enable the above use case, the following items need to be sorted out: 1) Communication between Accelerator and host CPU application 2) Implement the workload in Accelerator Since this is anyway discussed in today's TB meeting. I am sharing my thoughts here. IMO, There are two ways to do it: Way 1: 1) Introduce libraries specific to accelerator communication like gpudev, xpudev, dpudev etc 2) Implement the workload in accelerator specific fashion in the application. Pros: Cons: - Need for introducing multiple libraries for specific accelerator communication in DPDK - Specific application needs to be written for each accelerator that needs to be offloaded. Way 2: 1) Introduce the generic library for accelerator communication. 2) Application express the workload in a non-accelator specific fashion and let the accelerator implementation(Dont have the requirement to add it in DPDK code base) implement the functional model. Pros: - The same DPDK application can use to offload various accelerator technologies - More contributors can use the library as it is no specific one type of accelerator device Cons: > > If the HW support crosses over between projects it gets very complex. >