From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 41041A0C45; Wed, 20 Oct 2021 07:38:46 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 00B2E40150; Wed, 20 Oct 2021 07:38:45 +0200 (CEST) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) by mails.dpdk.org (Postfix) with ESMTP id 9925640142 for ; Wed, 20 Oct 2021 07:38:44 +0200 (CEST) Received: by mail-io1-f46.google.com with SMTP id z69so19993202iof.9 for ; Tue, 19 Oct 2021 22:38:44 -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=vswmDe5lj8IOeR6ubvS8Z+PP4eZYHX/gmSNWBNhA7JI=; b=mwjAWpOmbgLY7PAJ7uJ+PmRgWTVzYRrTWW7KClxSEKZeb1q3KkmPORcHcQaLMKFClc dse9ad+ZpOq8yOPNiBuJTVJqApulcuX0iMtnIr8jUon6Hne4dhjPemtevbRmwCNVBchf 8CbyFQU5tBldqxTJW2pLkVb4Bp0X8QNHHheDSORS/t9H1KGRNlF25g9GYaFhBOS7GrqY /qB9EKmV1u3TxfA//1o4xrUfSO5uI0hhA7bXMyrSpoXzl6QeoQ3dLcpHQDzlO1Ej8AE/ DEgyvMfozLeko5+tj/8ocjCtGl4YN80S3NdPo/4GBV49qCY4w51GWOJYgd3e8/Koq+S1 K2Sw== 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=vswmDe5lj8IOeR6ubvS8Z+PP4eZYHX/gmSNWBNhA7JI=; b=QvtOtK4LqRVP4VJ2k005+STdjh2CTEbXXxwjYKGXuZvyGjxZtYcLauBa1WfeLBF1dV Wd1FsAz7CohYhpusCUcXNwtgAxhToMJqXT1KEjRs37pkMIwPwP0QZeF9iAMo7yZYUghz urMUZu2i8k/zavm7IMujoc9t9Lt/mB0LjsCRq4unWtkF5TaYXVrN347cp7ZOOYp3oGjE iCJxpZ6jh9mjHdexcSPkvukMEjuO1qB6pyMD4dZMtOx74x+0mlmR/4XbN1mgri6SY5SM 4HPix1cDLIoiXIl+08qSoZ9vARmQL9mjoafP+PniaLjeKuPptld8eycienqYWnhTj1M2 gWsw== X-Gm-Message-State: AOAM532yU/vix2N9VVmBfAzDkTrGseia5Z4txjJ38GE8dF6A9xP810G/ dKch526os+oqr/44AdJKF4mBG5H8nF+swX03ayc= X-Google-Smtp-Source: ABdhPJwHTTCoWnWlJBcBqbUKWVJggtXLR+RNvGL8dJitNYUXitOqTWixnbYWrfng300RJIQ6oiq74Z6x/p7UGqLmaAs= X-Received: by 2002:a02:a14d:: with SMTP id m13mr7515282jah.126.1634708323890; Tue, 19 Oct 2021 22:38:43 -0700 (PDT) MIME-Version: 1.0 References: <20211019181459.1709976-1-jerinj@marvell.com> <6870595.fqHcUuC4to@thomas> In-Reply-To: From: Jerin Jacob Date: Wed, 20 Oct 2021 11:08:17 +0530 Message-ID: To: Tom Herbert Cc: Thomas Monjalon , Jerin Jacob , dpdk-dev , Ferruh Yigit , Ajit Khaparde , Andrew Boyer , Andrew Rybchenko , Beilei Xing , "Richardson, Bruce" , Chas Williams , "Xia, Chenbo" , Ciara Loftus , Devendra Singh Rawat , Ed Czeck , Evgeny Schemeilin , Gaetan Rivet , Gagandeep Singh , Guoyang Zhou , Haiyue Wang , Harman Kalra , heinrich.kuhn@corigine.com, Hemant Agrawal , Hyong Youb Kim , Igor Chauskin , Igor Russkikh , Jakub Grajciar , Jasvinder Singh , Jian Wang , Jiawen Wu , Jingjing Wu , John Daley , John Miller , "John W. Linville" , "Wiles, Keith" , Kiran Kumar K , Lijun Ou , Liron Himi , Long Li , Marcin Wojtas , Martin Spinler , Matan Azrad , Matt Peters , Maxime Coquelin , Michal Krawczyk , "Min Hu (Connor" , Pradeep Kumar Nalla , Nithin Dabilpuram , Qiming Yang , Qi Zhang , Radha Mohan Chintakuntla , Rahul Lakkireddy , Rasesh Mody , Rosen Xu , Sachin Saxena , Satha Koteswara Rao Kottidi , Shahed Shaikh , Shai Brandes , Shepard Siegel , Somalapuram Amaranath , Somnath Kotur , Stephen Hemminger , Steven Webster , Sunil Kumar Kori , Tetsuya Mukawa , Veerasenareddy Burru , Viacheslav Ovsiienko , Xiao Wang , Xiaoyun Wang , Yisen Zhuang , Yong Wang , Ziyang Xuan , Prasun Kapoor , nadavh@marvell.com, Satananda Burla , Narayana Prasad , Akhil Goyal , Ray Kinsella , Dmitry Kozlyuk , Anatoly Burakov , Cristian Dumitrescu , Honnappa Nagarahalli , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , "Ruifeng Wang (Arm Technology China)" , David Christensen , "Ananyev, Konstantin" , Olivier Matz , "Jayatheerthan, Jay" , Ashwin Sekhar Thalakalath Kottilveetil , Pavan Nikhilesh , Elena Agostini , David Marchand , felipe@sipanda.io, chethan@sipanda.io, siva@sipanda.io, Tom Herbert 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, Oct 20, 2021 at 2:12 AM Tom Herbert wrote: > > On Tue, Oct 19, 2021 at 12:36 PM Jerin Jacob wrote: > > > > On Wed, Oct 20, 2021 at 12:38 AM Thomas Monjalon 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? > > > > > It looks to be the role of the dataplane application to finely manage > > > how to use the hardware for a specific dataplane. > > > > It is possible with this scheme. > > > > > I believe the API for such layer would be either too big, or too limited, > > > or not optimized for specific needs. > > > > It will be optimized for specific needs as applications ask for what to do? > > not how to do? > > > > > If we really want to automate or abstract the HW/SW co-design, > > > I think we should better look at compiler work like P4 or PANDA. > > > > The compiler stuff is very static in nature. It can address the packet > > transformation > > workloads. Not the ones like IPsec or baseband offload. > > Another way to look at it, GPU RFC started just because you are not able > > to express all the workload in P4. > > Hi, > > Indeed, you may want to look at PANDA > (https://github.com/panda-net/panda) for this purpose especially with > regard to HW/SW co-design. Fundamentally, it is C/C++ so it's "Turing > Complete" as far as being able to express arbitrary workloads. The > program structure abstracts out any underlying details of the runtime > environment (hence it is "right once, run anywhere"). It is the > auspices of a compiler to convert the user's expression of intent into > optimized code for the backend; the backends can be software, such as > DPDK (which PANDA will soon support), or even hardware. In any case, > the code emitted will be optimized per the environment, taking > advantage of hardware acceleration for instance, which leads to the > PANDA mantra "write once, run anywhere, run well". This does require > APIs to control hardware acceleration, but our goal is to hide that > complexity from the user without the loss of benefits of emerging > hardware features. Also with emerging compiler techniques like LLVM's > MLIR and dynamically defined instructions, the historically "static" > nature of compilers can be undone. Thanks for the insight. These technologies we are using in Accelerator device and not host CPU interface. host-side is all about memory management, communication, and expressing the workload. And workload like vDPU application to offload ORAN 7.2 split for 5G RU device is much beyond packet processing. > > Tom > > > > > > > > > >