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 54F82A0C41; Tue, 19 Oct 2021 22:42:08 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0E1CC40142; Tue, 19 Oct 2021 22:42:08 +0200 (CEST) Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) by mails.dpdk.org (Postfix) with ESMTP id BFC664003E for ; Tue, 19 Oct 2021 22:42:06 +0200 (CEST) Received: by mail-pf1-f171.google.com with SMTP id m14so998855pfc.9 for ; Tue, 19 Oct 2021 13:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=5CsmUIuC9GVQfoKFNnWBYt+J3ntZiNuPEux1gtRpPxM=; b=GZ28q/QqM1j8oPrkPGIHvzFz5MU51mSfEX6UNhecoKn9pRFlGlL/A7j6Kwv5xlD7xj 3THItVoUj8x0Oh+uUUYRe6fHp3gDe22NmLCtA6xtBVEub0XjKNSVTOmZd8lkhfHiqAxp 6ns5LfKTk9Pc/9whWUbVDVJJtvdvYDsLrXjV0b9eu/jt7SxwnIQqrf61aPuD5MifHc5M SzdeULLgwoDjJ2D86RIxHjJbgOGF+2yRY0oK/dMAcPhstcRvDiLO0pJPOJDAYBKIiDqo mVfz8iRTek1/ghjqVE8XigTdJrPuTtuH69BiHK/TP1goaCD8E+U1UZKcvVovb9y9C4pj /rHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=5CsmUIuC9GVQfoKFNnWBYt+J3ntZiNuPEux1gtRpPxM=; b=Uteepq4FAlEm1OG1xTlMbnQXoUAb7EkXpH+3tYUetzGUk0DVjOkagmC7OXZR1gh86p aqiBEbWbp2ZFdsBF5iiML5X0HwqiMZCYYx9/2raoQspfTwIN/v/lqVpOox1kN83nPa7I wkZKp3+R/zJJLUvEZ25vVizEFnKYIr0udfNQopmByHoBSAUPSl5KWEjP1a4T0NTvg9xG MfGkSus1Cw1NxGtHhfoLYl+uDDTzmsKf/Y54W7uH4+DbY1HOS6/fPfQ5X6jg7Sl7nREQ laatgnFJKRWqpaTZpjojuPn74L5zOPkbk+YiDorK0Vre97wovwxMe7niIV3TdGiM8foQ wFbQ== X-Gm-Message-State: AOAM5335dN2G8sEYPftZCvtCvGtdPG9CgqnABFG6uluSCoMv7Q5evbBH p0KCUBZD3/h3kjCJh5oKbOrh6g== X-Google-Smtp-Source: ABdhPJwQ+xavVSOA51UtKpLJNmaKtJBauq5h5u3n8514xfXNtfzWzj+BgPqw6KRNGolsIkFYtDODNA== X-Received: by 2002:a62:7bd5:0:b0:44c:72f5:5da4 with SMTP id w204-20020a627bd5000000b0044c72f55da4mr2117055pfc.48.1634676125732; Tue, 19 Oct 2021 13:42:05 -0700 (PDT) Received: from hermes.local (204-195-33-123.wavecable.com. [204.195.33.123]) by smtp.gmail.com with ESMTPSA id 60sm3527869pjz.11.2021.10.19.13.42.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Oct 2021 13:42:05 -0700 (PDT) Date: Tue, 19 Oct 2021 13:42:00 -0700 From: Stephen Hemminger 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 , Mattias =?UTF-8?B?UsO2bm5ibG9t?= , "Ruifeng Wang (Arm Technology China)" , David Christensen , "Ananyev, Konstantin" , Olivier Matz , "Jayatheerthan, Jay" , Ashwin Sekhar Thalakalath Kottilveetil , Pavan Nikhilesh , Elena Agostini , David Marchand , tom@herbertland.com Message-ID: <20211019134200.50322420@hermes.local> In-Reply-To: References: <20211019181459.1709976-1-jerinj@marvell.com> <6870595.fqHcUuC4to@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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, 20 Oct 2021 01:06:10 +0530 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 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. If the HW support crosses over between projects it gets very complex.