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 915A7A0C45; Wed, 20 Oct 2021 08:01:32 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 49E1A40150; Wed, 20 Oct 2021 08:01:32 +0200 (CEST) Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by mails.dpdk.org (Postfix) with ESMTP id 910F14003E for ; Tue, 19 Oct 2021 22:42:23 +0200 (CEST) Received: by mail-ed1-f52.google.com with SMTP id r4so10895898edi.5 for ; Tue, 19 Oct 2021 13:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Yi+innqQFFqPRL5DcnuUTVAEwRpjTo8vMg3hhZsjOG8=; b=KjaSNqOt5xEj24djYqZ0CuHkocEA3NhFhJPCRJ6N9yQOClTG3pD+B4a61UWbUIlov4 cgOwCRBnZlHVVSxdBgg3Z3XCAeQ6DfZM/+faSoAGCu4qcU3dLG0TFMJEZdZmBwN4XSBZ efCrDh9l6v20CGEL0qRqNkkvCTaEFs6XN6JZ4lrGrqqdRWfsLkDgKRFvwopRCNqCdgNS FNHAdTtvzw7CJlHa9vrfuv9mF07cBqHWQtQY+wNVTwlvc2DCdPgYUXgtbp0UyfQ8PP7g bByPIK8UpP8TZfhpScyt+BpQi0Fl6qVobYEF7fnUK2Xj6g2mOrsNVqaNX9u8nynsi+Qu O2ig== 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=Yi+innqQFFqPRL5DcnuUTVAEwRpjTo8vMg3hhZsjOG8=; b=7mwZ397eYh6VYzWoLp+oal/IUMRAbxEKQSH5s45SD/KUR6Zj2M6UCGc7l1fX+9l+46 8fFjOQIuQaWHGgRK425wd0F7WABRbCw6CUkoRSMKZY1QpX53vTFhDldumAGHj/sqWmIy xtr0//0mLexHOEMzB9adSL3rFWL5r+TzVvfxQ1+uDc1b8Y3ASudKWli75L5FkpHrNZfd O8njLHSjvWEtMkWFBP9MDJ7cx7cRGqxz6mD7d2UWNJzUMMibCbJmM4TcKdyUFt3KmOUJ fMHjRZNBgwbFvSEQEynWKLYBgTv9X2PlH3oon9jpRoo/jGXxpQMViwrfjGDsYU4gVh/M aGlg== X-Gm-Message-State: AOAM5328QwFDYEjN4Yn6sX9OvL2E7ypZ8YNK3JB5UhKI2JZi4vU7WJVV tCeSAVeE1ml7uIQOrK/RX0mUIeFUHiLly8uWi7LdvQ== X-Google-Smtp-Source: ABdhPJyqn5pJWm6s6rHSvii8NIkHiKemkYm36fhhfE6YTX4HfWeoTiJczl0AWHUUOE0yBY7Ars7o9w+YU+0UU0WTm0I= X-Received: by 2002:a17:906:994b:: with SMTP id zm11mr41367101ejb.294.1634676143127; Tue, 19 Oct 2021 13:42:23 -0700 (PDT) MIME-Version: 1.0 References: <20211019181459.1709976-1-jerinj@marvell.com> <6870595.fqHcUuC4to@thomas> In-Reply-To: From: Tom Herbert Date: Tue, 19 Oct 2021 13:42:11 -0700 Message-ID: To: Jerin Jacob 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" X-Mailman-Approved-At: Wed, 20 Oct 2021 08:01:31 +0200 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 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. Tom > > > > >