From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 782CFC433F5 for ; Thu, 11 Nov 2021 11:44:48 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 0A57E61260 for ; Thu, 11 Nov 2021 11:44:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0A57E61260 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 690934113D; Thu, 11 Nov 2021 12:44:47 +0100 (CET) Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) by mails.dpdk.org (Postfix) with ESMTP id 5C82040E2D; Thu, 11 Nov 2021 12:44:46 +0100 (CET) Received: by mail-io1-f41.google.com with SMTP id x10so6544573ioj.9; Thu, 11 Nov 2021 03:44:46 -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=yA5hFYwMKxdu7w+QOmenBdrrSat4YG7WeFbs2aE8RrQ=; b=nkAlNMjoeedY52nQIUs8BOUQeVUgb7HhWLgnTEw6v4cXUgfxkg4TI2G5iO/8KdTjvO gyYiJTUnrurG2PivXipoz1I2bGyaQLyAmk42BVn3Qy3etNqUdXTt0QpjS+qo0iif9/Et lLbMCKtjWRtuVmlbKGYYzRSNdaQfnN101iTG1lyskO74Wm5nCDNx1RXal/PujvmyYAJ7 8hRLn6hiwMJe8qs4IBG7hIM9DR82rS5o9pkiolZsEbkb/36IeEMpL4szMnEftFyE62FQ RqcqjXECjM63793n3VPVAGchBbFwd0/B95P3pYzmxM7NZcFwV3gUXkiKYFHjahkj7SJj YxeQ== 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=yA5hFYwMKxdu7w+QOmenBdrrSat4YG7WeFbs2aE8RrQ=; b=v/g2WzARhzRENeHkwPqY4Gv7PEzVDJ4ysUInJzMTEjAMSScznWiCTD4/CI0NsTqAK5 AUwDcOS+7sBV/zhozOOOIf+91suBVgyHtfjtc+c4X+M7nPHjpalgr0SL30y9c61myb9B RCtjkEHRmmtbqlBd7rbnMafXmxjZKoMuTpGDv0Dty4I/6O7HuWDyt92PWJqYBL8jXfIY wxcI2KRK+PvZZWjdjHUzhgoDUtR7pf8sA+EdnUbOv3747lWJORo2G2dlKuoD2sV9W6/j 0xeFErR5w5jLYjjb4qx8GD9scCWRJjX7eRropJneWraA3R3GZ7I+Se+GPL4+Wty2+3UT aqMw== X-Gm-Message-State: AOAM532JDpC9hJnj24hkdNZ0c7K9mZ8mNKYwOL6jEFQBGA8PWQivxtia AHSdfa39hYqcEW0v1NPE5SCrOsSF74OApBGxMrY= X-Google-Smtp-Source: ABdhPJwPu8HsekIsT8K5aDxrRGdLsknTtb4DqULl3eNXdXcMAIniA3z5MRSovjt7vqs5s4uzIYDywGcUzbd4p41gtTU= X-Received: by 2002:a05:6602:164a:: with SMTP id y10mr4251062iow.123.1636631085619; Thu, 11 Nov 2021 03:44:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jerin Jacob Date: Thu, 11 Nov 2021 17:14:19 +0530 Message-ID: Subject: Re: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27 To: "Ananyev, Konstantin" , Thomas Monjalon , 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 , Olivier Matz , "Jayatheerthan, Jay" , Ashwin Sekhar Thalakalath Kottilveetil , Pavan Nikhilesh , Elena Agostini Cc: "dev@dpdk.org" , "techboard@dpdk.org" 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 Tue, Nov 2, 2021 at 9:35 PM Ananyev, Konstantin wrote: > > 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/DM6PR12MB41079FAE6B5DA35102B1BBFACDB79@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? [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). > >