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 A3B01A0547; Fri, 29 Oct 2021 17:52:14 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 91C25411DD; Fri, 29 Oct 2021 17:52:14 +0200 (CEST) Received: from mail-il1-f169.google.com (mail-il1-f169.google.com [209.85.166.169]) by mails.dpdk.org (Postfix) with ESMTP id 4062C4111F for ; Fri, 29 Oct 2021 17:52:13 +0200 (CEST) Received: by mail-il1-f169.google.com with SMTP id w10so11056389ilc.13 for ; Fri, 29 Oct 2021 08:52:13 -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:content-transfer-encoding; bh=+fqbNw7RuHaaothENQvyLaj2HqWE6YeJmUNh1A3Dn0M=; b=a4nYjXZGv4ouo4CMhHxCjSZSVRnoH2pZUYrKer/0Gb5DAEihtPiyqBMGSEbGUqysgW p8KcN/RSTnWSpQCy7FRTf26PAL+Sbv64sX0qGNTOKTfM81XvDdD9FZb0mQS8Atlt9mAj FACYdYc7w8q/BqfDYjn7v1JLaI6XtC8DtwqUHZOuIiHAWTXIeiEKlTdJuAk/GibOniCs kjJGhOeTmGJl5y7ExObAjjwDM/lY0/IRSmcwmGXFF2HcBt5EdzhpJ3pQVLvXpvpSGQW2 FME49YGbc634F6N6Om2VRIEGzvpQi8gqf546TjIFwkkmUklFfpl02gTl4wNayVcxW/x1 i6Ng== 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:content-transfer-encoding; bh=+fqbNw7RuHaaothENQvyLaj2HqWE6YeJmUNh1A3Dn0M=; b=1jyxQ2QusvSGsetzfO6j78JXHZfXUahoTuKhY0EaJ47uZtxurhLxTqgdGC/jt9MZyD tr1bnQITqezloGPLnxCEtpKlVq0q5rsGkaQMNGO00RVLg6yfC82NYRlBn2MlyFbkHP7q 9dWywVVqUHLGNL1/upyNe04N1Aka8ghFxwsffdY3fk+nRJO2OpyZnyuvAX2NPvZgvorM BzAkKGQynyIKIs6XmnK5gdOnEbiYwpTe6qHGD1tqNw1ph5QpwqmGlG2AZMEojdwlW7A2 64TMgDmqxwP0OWZrRzpBWIL400wk6514dPvu+JCZRWz1sv7EsU+j/BjXf/MDonCxG/U6 AG0Q== X-Gm-Message-State: AOAM530KaHfWhJnFiPBg3GxTdy42TobJg3qcLBi/sLeEwy48AqfsNWfk +r4DZUvmlen9E/pD10K0qvsXAEioUTx6D2PvjgM= X-Google-Smtp-Source: ABdhPJwnIlm1TsmXCs/awUQPmwvfbfoK2CtpAhSwQOvftFDemEuc4jyknEAlDafMs53jRojQ4u69B4NPjKhfjkGydMs= X-Received: by 2002:a05:6e02:1a2d:: with SMTP id g13mr8589959ile.295.1635522732491; Fri, 29 Oct 2021 08:52:12 -0700 (PDT) MIME-Version: 1.0 References: <20211019181459.1709976-1-jerinj@marvell.com> <35f086cb-bef3-9a11-6a85-7e695c0b0e7c@ericsson.com> In-Reply-To: <35f086cb-bef3-9a11-6a85-7e695c0b0e7c@ericsson.com> From: Jerin Jacob Date: Fri, 29 Oct 2021 21:21:45 +0530 Message-ID: To: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= Cc: "jerinj@marvell.com" , "dev@dpdk.org" , "thomas@monjalon.net" , "ferruh.yigit@intel.com" , "ajit.khaparde@broadcom.com" , "aboyer@pensando.io" , "andrew.rybchenko@oktetlabs.ru" , "beilei.xing@intel.com" , "bruce.richardson@intel.com" , "chas3@att.com" , "chenbo.xia@intel.com" , "ciara.loftus@intel.com" , "dsinghrawat@marvell.com" , "ed.czeck@atomicrules.com" , "evgenys@amazon.com" , "grive@u256.net" , "g.singh@nxp.com" , "zhouguoyang@huawei.com" , "haiyue.wang@intel.com" , "hkalra@marvell.com" , "heinrich.kuhn@corigine.com" , "hemant.agrawal@nxp.com" , "hyonkim@cisco.com" , "igorch@amazon.com" , "irusskikh@marvell.com" , "jgrajcia@cisco.com" , "jasvinder.singh@intel.com" , "jianwang@trustnetic.com" , "jiawenwu@trustnetic.com" , "jingjing.wu@intel.com" , "johndale@cisco.com" , "john.miller@atomicrules.com" , "linville@tuxdriver.com" , "keith.wiles@intel.com" , "kirankumark@marvell.com" , "oulijun@huawei.com" , "lironh@marvell.com" , "longli@microsoft.com" , "mw@semihalf.com" , "spinler@cesnet.cz" , "matan@nvidia.com" , "matt.peters@windriver.com" , "maxime.coquelin@redhat.com" , "mk@semihalf.com" , "humin29@huawei.com" , "pnalla@marvell.com" , "ndabilpuram@marvell.com" , "qiming.yang@intel.com" , "qi.z.zhang@intel.com" , "radhac@marvell.com" , "rahul.lakkireddy@chelsio.com" , "rmody@marvell.com" , "rosen.xu@intel.com" , "sachin.saxena@oss.nxp.com" , "skoteshwar@marvell.com" , "shshaikh@marvell.com" , "shaibran@amazon.com" , "shepard.siegel@atomicrules.com" , "asomalap@amd.com" , "somnath.kotur@broadcom.com" , "sthemmin@microsoft.com" , "steven.webster@windriver.com" , "skori@marvell.com" , "mtetsuyah@gmail.com" , "vburru@marvell.com" , "viacheslavo@nvidia.com" , "xiao.w.wang@intel.com" , "cloud.wangxiaoyun@huawei.com" , "yisen.zhuang@huawei.com" , "yongwang@vmware.com" , "xuanziyang2@huawei.com" , "pkapoor@marvell.com" , "nadavh@marvell.com" , "sburla@marvell.com" , "pathreya@marvell.com" , "gakhil@marvell.com" , "mdr@ashroe.eu" , "dmitry.kozliuk@gmail.com" , "anatoly.burakov@intel.com" , "cristian.dumitrescu@intel.com" , "honnappa.nagarahalli@arm.com" , "ruifeng.wang@arm.com" , "drc@linux.vnet.ibm.com" , "konstantin.ananyev@intel.com" , "olivier.matz@6wind.com" , "jay.jayatheerthan@intel.com" , "asekhar@marvell.com" , "pbhagavatula@marvell.com" , Elana Agostini Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Fri, Oct 29, 2021 at 5:27 PM Mattias R=C3=B6nnblom wrote: > > On 2021-10-25 11:03, Jerin Jacob wrote: > > On Mon, Oct 25, 2021 at 1:05 PM Mattias R=C3=B6nnblom > > wrote: > >> On 2021-10-19 20:14, jerinj@marvell.com wrote: > >>> From: Jerin Jacob > >>> > >>> > >>> Dataplane Workload Accelerator library > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> > >>> 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. > >> > >> There are already several instances of DPDK devices with pure-software > >> implementation. In this regard, a DPU/SmartNIC represents nothing new. > >> What's new, it seems to me, is a much-increased need to > >> configure/arrange the processing in complex manners, to avoid bouncing > >> everything to the host CPU. > > Yes and No. It will be based on the profile. The TLV type TYPE_USER_PLA= NE will > > have user plane traffic from/to host. For example, offloading ORAN spli= t 7.2 > > baseband profile. Transport blocks sent to/from host as TYPE_USER_PLANE= . > > > >> Something like P4 or rte_flow-based hooks or > >> some other kind of extension. The eventdev adapters solve the same > >> problem (where on some systems packets go through the host CPU on thei= r > >> way to the event device, and others do not) - although on a *much* > >> smaller scale. > > Yes. Eventdev Adapters only for event device plumbing. > > > > > >> > >> "Not-fixed function" seems to call for more hot plug support in the > >> device APIs. Such functionality could then be reused by anything that > >> can be reconfigured dynamically (FPGAs, firmware-programmed > >> accelerators, etc.), > > Yes. > > > >> but which may not be able to serve as a RPC > >> endpoint, like a SmartNIC. > > It can. That's the reason for choosing TLVs. So that > > any higher level language can use TLVs like https://protect2.fireeye.co= m/v1/url?k=3D96886daf-c91357b6-96882d34-8682aaa22bc0-c994a5dcbda5d9e8&q=3D1= &e=3De89c0aca-a3b3-4f72-b616-ba4550b856b6&u=3Dhttps%3A%2F%2Fgithub.com%2Fus= tropo%2Futtlv > > to communicate with the accelerator. TLVs follow the request and > > response scheme like RPC. So it can warp it under application if needed= . > > > >> > >> DWA could be some kind of DPDK-internal framework for managing certain > >> type of DPUs, but should it be exposed to the user application? > > > > Could you clarify a bit more. > > The offload is represented as a set of TLVs in generic fashion. There > > is no DPU specific bit in offload representation. See > > rte_dwa_profiile_l3fwd.h header file. > > > It seems a bit cumbersome to work with TLVs on the user application > side. Would it be an alternative to have the profile API as a set of C > APIs instead of TLV-based messaging interface? The underlying > implementation could still be - in many or all cases - be TLVs sent over > some appropriate transport. The reason to pick TLVs is as follows 1) Very easy to enable ABI compatibility. (Learned from rte_flow) 2) If it needs to be transported over network etc it needs to be packed so that way it is easy for implementation to do that with TLV also it gives better performance in such cases by avoiding reformatting or possibly avoiding memcpy etc. 3) It is easy to plugin with another high-level programing language as just one API 4) Easy to decouple DWA core library functionalities from profile. 5) Easy to enable asynchronous scheme using request and response TLVs. 6) Most importantly, We could introduce type notion with TLV (connected with the type of message See TYPE_ATTACHED, TYPE_STOPPED, TYPE_USER_PLANE etc ), That way, we can have a uniform outlook of profiles instead of each profile coming with a setup of its own APIs and __rules__ on the state machine. I think, for a framework to leverage communication mechanisms and other aspects between profiles, it's important to have some synergy between profi= les. Yes. I agree that a bit more logic is required on the application side to use TLV, But I think we can have a wrapper function getting req and response structu= res. > > Such a C API could still be asynchronous, and still be a profile API > (rather than a set of new DPDK device types). > > > What I tried to ask during the meeting but where I didn't get an answer > (or at least one that I could understand) was how the profiles was to be > specified and/or documented. Maybe the above is what you had in mind > already. Yes. Documentation is easy, please check the RFC header file for Doxygen meta to express all the attributes of a TLV. +enum rte_dwa_port_host_ethernet { + /** + * Attribute | Value + * ----------|-------- + * Tag | RTE_DWA_TAG_PORT_HOST_ETHERNET + * Stag | RTE_DWA_STAG_PORT_HOST_ETHERNET_H2D_INFO + * Direction | H2D + * Type | TYPE_ATTACHED + * Payload | NA + * Pair TLV | RTE_DWA_STAG_PORT_HOST_ETHERNET_D2H_INFO + * + * Request DWA host ethernet port information. + */ + RTE_DWA_STAG_PORT_HOST_ETHERNET_H2D_INFO, + /** + * Attribute | Value + * ----------|--------- + * Tag | RTE_DWA_TAG_PORT_HOST_ETHERNET + * Stag | RTE_DWA_STAG_PORT_HOST_ETHERNET_D2H_INFO + * Direction | H2D + * Type | TYPE_ATTACHED + * Payload | struct rte_dwa_port_host_ethernet_d2h_info + * Pair TLV | RTE_DWA_STAG_PORT_HOST_ETHERNET_H2D_INFO + * + * Response for DWA host ethernet port information. + */ + RTE_DWA_STAG_PORT_HOST_ETHERNET_D2H_INFO,