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 39A25A0548; Fri, 12 Nov 2021 07:20:22 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 02DDF40692; Fri, 12 Nov 2021 07:20:22 +0100 (CET) Received: from mail-il1-f179.google.com (mail-il1-f179.google.com [209.85.166.179]) by mails.dpdk.org (Postfix) with ESMTP id 420BB40687; Fri, 12 Nov 2021 07:20:21 +0100 (CET) Received: by mail-il1-f179.google.com with SMTP id h2so8027938ili.11; Thu, 11 Nov 2021 22:20:21 -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=pt+Sqd96sH8r43a5ha9OIAHq011ZZtEOYwL16b7ATmo=; b=aqCohNdDPM21GRpC0HR17vy6eb1GU0dBA0Jp9BT6ch6uSYZRthYJo+TuWN+AuGEQ1C LCGnaITUHqblMRS6SNHDVG9ed5rkx/TF2nnED7T7jgnd8x+9vOlyLn8T8CvBODyNAWIv oapaah9UW/0KmuMmJ+oijaCIfKTMmqKGdFmNK9QuvT9Bjbnpgw+qpwxErndGVOcuY1i3 bFcGPnP4+ZE8kM1yS8DcugB2TnTMDFc2VYsnWM2I/hPp59hawGLp08sGR/ba37ca9/mw ryFvUo+7fBG6J6TRnlfDlYfho3UuSiryHjt74hxn+DnvVtbLOhmiblAoMWgwf7xNp/pN nSYg== 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=pt+Sqd96sH8r43a5ha9OIAHq011ZZtEOYwL16b7ATmo=; b=lvhqQVImQCRxQshkJpvz2Al441ZdyrVPErN1ZPkBxF/IQfLwQ9aKKhZZo8YLgB2rg9 RAz7CiqwhQ/uY1FWuhmgPyp3He+3TRtyYWR+8LVnxK3b/Vz1WuefN9zr13hfAIgWl7HE GcZAGKhfbDprnWuB2HZNdyVQi3meSSGY6+e1qdcCpaKmx/QxsYTbS9jk5ThEbwXoIkrm L3VSQETKFr3IqYwm2Apq6BhzGowUaJRPzZPElhwAXpDzaFJ79J2ryZNOKLHgUodRH2G+ 2QoCDGHMf4Ixn54VicSt0vJGtrBpHrHpZTuYmZ+RjnI1b4eQ0veX6WNov8lqHKKYAkPT tL1w== X-Gm-Message-State: AOAM531dMQkT44fMbgg+lbN7VDsLdtNBDxlgqMZXnfNe/oXgWVZixgkk D1Oce+LbJG1mxyO94gvR6s7skXmIEpCn9lvxYxU= X-Google-Smtp-Source: ABdhPJzvaK8i9jTug5VGsDGfX6rZrcX0WxV7A63Y7f5JDSvtgVvFhHqUj93SkT+hUfEz9zYLKNTpb/zh3BGW5/Bzwoo= X-Received: by 2002:a05:6e02:170a:: with SMTP id u10mr7748584ill.251.1636698020600; Thu, 11 Nov 2021 22:20:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jerin Jacob Date: Fri, 12 Nov 2021 11:49:54 +0530 Message-ID: Subject: Re: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27 To: "Ananyev, Konstantin" Cc: Honnappa Nagarahalli , "thomas@monjalon.net" , "Yigit, Ferruh" , "Ajit Khaparde (ajit.khaparde@broadcom.com)" , Andrew Boyer , Andrew Rybchenko , "Xing, Beilei" , "Richardson, Bruce" , Chas Williams , "Xia, Chenbo" , "Loftus, Ciara" , Devendra Singh Rawat , Ed Czeck , Evgeny Schemeilin , Gaetan Rivet , Gagandeep Singh , Guoyang Zhou , "Wang, Haiyue" , Harman Kalra , "heinrich.kuhn@corigine.com" , "hemant.agrawal@nxp.com" , Hyong Youb Kim , Igor Chauskin , Igor Russkikh , Jakub Grajciar , "Singh, Jasvinder" , Jian Wang , Jiawen Wu , "Wu, Jingjing" , "Daley, John" , John Miller , "John W. Linville" , "Wiles, Keith" , Kiran Kumar K , Lijun Ou , Liron Himi , Long Li , Marcin Wojtas , Martin Spinler , Matan Azrad , "Peters, Matt" , Maxime Coquelin , Michal Krawczyk , "Min Hu (Connor" , Pradeep Kumar Nalla , Nithin Dabilpuram , "Yang, Qiming" , "Zhang, Qi Z" , Radha Mohan Chintakuntla , Rahul Lakkireddy , Rasesh Mody , "Xu, Rosen" , 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 , "Wang, Xiao W" , Xiaoyun Wang , Yisen Zhuang , "Wang, Yong" , Ziyang Xuan , Prasun Kapoor , "nadavh@marvell.com" , Satananda Burla , Narayana Prasad , Akhil Goyal , Ray Kinsella , Dmitry Kozlyuk , "Burakov, Anatoly" , "Dumitrescu, Cristian" , "mattias.ronnblom" , 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 12, 2021 at 7:17 AM Ananyev, Konstantin wrote: > > > > > > > > > > > > > > > > Hi Jerin, > > > > > > > > Minutes of Technical Board Meeting, 2021-Oct-27 > > > > > > > > > > Members Attending > > > > > --------------------------- > > > > > -Aaron > > > > > -Ferruh > > > > > -Hemant > > > > > -Honnappa > > > > > -Jerin > > > > > -Kevin > > > > > -Konstantin (Chair) > > > > > -Maxime > > > > > -Stephen > > > > > -Thomas > > > > > > > > > > NOTE: The technical board meetings every second Wednesday at > > > > > https://meet.jit.si/DPDK at 3 pm UTC. > > > > > Meetings are public, and DPDK community members are welcome to > > > attend. > > > > > > > > > > NOTE: Next meeting will be on Wednesday 2021-Nov-03 @3pm UTC, and > > > > > will be chaired by Maxime. > > > > > > > > > > > > > > > GPUDEV library / DWA library inclusion > > > > > > > > http://inbox.dpdk.org/dev/DM6PR12MB41079FAE6B5DA35102B1BBFACDB7 > > > 9@DM6PR12MB4107.namprd12.prod.outlook.com/ > > > > > http://mails.dpdk.org/archives/dev/2021-October/226070.html > > > > > > > > > > > > > > > 1. GPU dev > > > > > ========= > > > > > > > > > > Pros: > > > > > - simple and clean API > > > > > - address particular needs: > > > > > - external (GPU) memory management within DPDK > > > > > - provides generic framework for CPU-GPU-NIC interaction > > > > > - Not specific to any particular workload > > > > > - GPU program creation/upload is out of scope for this framework > > > > > > > > > > Concerns: > > > > > - Framework is specific for just one particular accelerator class (GPU) > > > > > If we go that way, does it mean we'll need a separate library/API for > > > each > > > > > new HW device class (FPGA, etc.)? > > > > > > > > > > 2. DWA dev > > > > > ========== > > > > > > > > > > Pros: > > > > > - HW neutral abstraction for accelerator communication > > > > > - HW neutral abstraction for workload definitions (via profile) > > > > > - Ability to chain services provided by HW (chain multiple profiles) > > > > > - Sounds like really good approach for SoCs > > > > > > > > > > Concerns: > > > > > - Not easy to agree/define mandatory/optional features for each > > > > > particular profile > > > > > - User limited to particular already implemented profiles (longer > > > > > time to market, etc.) > > > > > - Richness of features might cause overcomplication in both internal > > > > > design/implementation and public API > > > > > > > > > > Conclusion > > > > > ========= > > > > > > > > > > At that stage it is really hard to predict which approach will be more > > > successful. > > > > > As both paths can co-exist within DPDK: > > > > > > > > > > 1) Go ahead with both approaches as experimental lib/drivers inside > > > > > DPDK > > > > > > > > Now that there is approval from TB. > > > > > > > > I would like to ask, Is anyone planning to review the specification > > > > header file [1]? > > > > > > > > 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. > > > > 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? > > > > > > I'd say (4) is a good thing to have. > > > Will allow people to try/test DWA approach and framework itself without > > > access to specific HW. > > Agree in general it is good as a standard of the expected behavior. But, it might be difficult/complex to implement all the profiles. For ex: L1 > > processing for 5G. > > From my understanding, Jerin talks about > SW implementation for only one profile for now (L3FWD). Yes. Only for one profile for now(L3FWD). We don't have plan for emulating complex profiles like L1 Processing for 5G.(I believe it is not even possible with the required quality) > > > > > > > > > > [1] > > > > http://mails.dpdk.org/archives/dev/2021-October/226070.html > > > > > > > > > > > > > 2) Re-evaluate both approaches in one year time > > > > > 3) Both should follow usual DPDK policy for new lib/device classes: > > > > > generic framework plus at least one driver implementation > > > > > 4) Both should be usable with open-source tools > > > > > (no exclusive dependency on third-party proprietary SW). > > > > > > > > > >