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 7FAF7A0C47; Fri, 19 Nov 2021 05:35:24 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 07E6240143; Fri, 19 Nov 2021 05:35:24 +0100 (CET) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) by mails.dpdk.org (Postfix) with ESMTP id 44C7240140; Fri, 19 Nov 2021 05:35:23 +0100 (CET) Received: by mail-io1-f43.google.com with SMTP id z26so11200434iod.10; Thu, 18 Nov 2021 20:35:23 -0800 (PST) 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=AakBg4WGWMY3g++h7JMTxOLLn7efnKhwFQN78BtgC1s=; b=qUBVyhzSy9Gk30Lh0+oxEasig+LTAWo7ljyI4DVnDsI5Pz/G/p2EBt+9vixbKCw2FQ Dzqga9qXAfHcyOw2FUlZTSkyZEGR3LagWHfU4TLUgh9fBivHx0LOzs8P40JiuwrCCkh4 zGXB0T/6+Kah2VMT6M+gkDSDM8ikCysF0u432lVAyJbgcWj8EbpnES22ztuReupDd+wb tYH3phykTPLQMTkXYzB2x5wwltXo+5tRrQPlj7QLMjmFjJAumPz0UYO5T2GDY+s8MjAY 8ERRu+J3SGG9EYGknckoM05580/MfFf5I6bBaiK7RGPHAhybENk3OgiBvx9/EZMro9Nj 7yng== 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=AakBg4WGWMY3g++h7JMTxOLLn7efnKhwFQN78BtgC1s=; b=KPNn9bfiKyNVpAUaSugcxIBVI92aSLt6wExSlCW4vzFVjXFkaqAQY4R4jbzwggDC8d +Bf5ZJUSq0WYZRBFaGEDOGhDST3OlddjojqzPZMbQ5NVn82M6rkbdr0Oyz05AbU/Ovcp svo7hz4rk8DspIOZVlTWTG2nOs1ENAEgGChdbja2I/RGOT64v9b3vfQacJ3NE1/YEfCT AM2w7yqYGVYxH/G/NUJ0FjFS+iZ1Ih97W0WmDxp7A1q4WYCn5uLMvYGq0zRrYQexQyy3 OWPFk0YT97GAsYN11pRNr5HTRTFrKitKMhWy671VbsYbUhVNr8LuSOcsF/jPB3Yj8qDB YGWA== X-Gm-Message-State: AOAM5309dgguYe3ozJtnHyJVcmb34ihu0M9cWVU0YBaUxpskS/6hC6vb /mMotL5xVZlDJmol23qd4CPejXZB9H/gJXVcDa8= X-Google-Smtp-Source: ABdhPJwSt8qiJeGUyvyZ2bfPIRJASoVHspKt9iqBW+Fz0KdDI94fWcD2xvaGy4UdrMi5NiOl2+/YEkBtev1vRBUbP3Q= X-Received: by 2002:a02:c60b:: with SMTP id i11mr25482529jan.15.1637296522202; Thu, 18 Nov 2021 20:35:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jerin Jacob Date: Fri, 19 Nov 2021 10:04:56 +0530 Message-ID: Subject: Re: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27 To: Honnappa Nagarahalli Cc: "Ananyev, Konstantin" , "thomas@monjalon.net" , Ferruh Yigit , "Ajit Khaparde (ajit.khaparde@broadcom.com)" , 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@nxp.com" , 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 , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , Ruifeng Wang , David Christensen , Olivier Matz , "Jayatheerthan, Jay" , Ashwin Sekhar Thalakalath Kottilveetil , Pavan Nikhilesh , Elena Agostini , "dev@dpdk.org" , "techboard@dpdk.org" , nd Content-Type: text/plain; charset="UTF-8" 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 On Fri, Nov 19, 2021 at 1:39 AM Honnappa Nagarahalli wrote: > > > > > > > > > > > There was a comment to remove the TLV length. I will do that > > > > > > next version with implementation. > > > > > > > > > > > > Identified the following set of work for this. > > > > > > > > > > > > 1) Common code at lib/dwa/ > > > > > > 2) Marvell DPU based driver at drivers/dwa/cnxk/ > > > > > > 3) Test application at app/test-dwa/ > > > > > > 4) It is possible to have an SW driver(To allow non-specialized > > > > > > HW to use the > > > > > > framework) for this by: > > > > > > a) Emulate DWA HW as a separate DPDK process > > > > > > b) Add drivers/dwa/sw/ and use memif driver so to create a > > > > > > communication channel between emulated DWA HW process and > > DPDK > > > > application. > > > > > Why use memif driver? Why not ring-pmd? > > > > > > > > Planning to emulation DWA accelerator functional model as a separate > > > > DPDK process in SW case. > > > You mean the primary and secondary processes correct? > > > > Primary and Primary. (DWA emulation as a separate primary process to mimic > > the real-world scenario) > > > > > > > > > Therefore memif is the ideal choice as it supports zero-copy of the > > > > data as well. > > > > https://doc.dpdk.org/guides/nics/memif.html > > > Zero-copy in memif is nothing but exchanging pointers to shared data. > > > The rings work across the primary and secondary processes and are always > > zero-copy. > > > We are doing some perf comparisons between memif and rings, will let you > > know once we have the data. > > > > Ok. > > I think between primary to primary memif will be required. > Agree, memif is easier/required between primary to primary. But, using it with zero-copy would need additional code on the application part in this scenario. The memory being shared needs to be mapped in both the processes. The existing memif driver does it internally for all memsegs [1]. Even if it is not, it will be abstracted in profile and driver, to make the application transparent on transport aspects. [1] static int memif_regions_init(struct rte_eth_dev *dev) { struct pmd_internals *pmd = dev->data->dev_private; int ret; /* * Zero-copy exposes dpdk memory. * Each memseg list will be represented by memif region. * Zero-copy regions indexing: memseg list idx + 1, * as we already have region 0 reserved for descriptors. */ if (pmd->flags & ETH_MEMIF_FLAG_ZERO_COPY) { /* create region idx 0 containing descriptors */ ret = memif_region_init_shm(dev, 0); if (ret < 0) return ret; ret = rte_memseg_walk(memif_region_init_zc, (void *)dev->process_private); if (ret < 0) return ret; } else { /* create one memory region contaning rings and buffers */ ret = memif_region_init_shm(dev, /* has buffers */ 1); if (ret < 0) return ret; } return 0; } > > > > > > > > > > > > > > > > > > > > > c) Add drivers/dwa/sw/profiles//l3fwd - To implement l3fwd > > > > > > profile using DPDK libraries for SW driver. > > > > > > > > > > > > I think, Item (4) aka SW drivers as useful(We don't need to > > > > > > implement for all profiles, I think, just for l3fwd it make > > > > > > sense to add, to allow to use of the framework in just SW mode). > > > > > > Is there any opinion on adding item (4) in DPDK? I saw mixed > > > > > > opinions earlier on this. I would like to understand, Is there > > > > > > any objection to doing > > > > > > item(4) in DPDK as it needs a good amount of work and I don't > > > > > > want to do throw it away if the community doesn't like this. > > > > > > Any opinion? > > > > > > > > > > > > [1] > > > > > > http://mails.dpdk.org/archives/dev/2021-October/226070.html > > > > > > > > > > >