From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0B697A0557; Sat, 22 Feb 2020 10:05:59 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BBE9D1BFC7; Sat, 22 Feb 2020 10:05:57 +0100 (CET) Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by dpdk.org (Postfix) with ESMTP id 8E7011BFAC; Sat, 22 Feb 2020 10:05:56 +0100 (CET) Received: by mail-io1-f67.google.com with SMTP id i11so5041774ioi.12; Sat, 22 Feb 2020 01:05:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JfyJWjPymy5iHECOa2BS0HZbqtIDvQkG1i61+5f3wNM=; b=IXGHbkqz3MvYNcbfiGo1Y4LLPQBitsYwwtn41Lp2QKwMBfJY4NVSCQ0aYewSBmhRZm Fe0B+YTzsosn7Omds69Vur1XBKE790BMqYYmALFjfKcHXeFORJopVzDPoegxyd0WrPgN cUFrPmRF1iHUnXuWjoMSbU1Qn5B39SBrLbatv8hwxnKJryPgjJUdj0E1rD4VJNdFl15K MiVts2o9Sy8ng32mw7Q81CVylO+Mw+qFrjxXBr2ELZTLpkE9eLpbjp7k8s1+ep68q19C zRussoIcsVD+SxIlI/X8dbb6Jg7eG/xTuPSD3VojC6mmwmKOaNE5ffrJWBl8b/E5NTbg rAFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JfyJWjPymy5iHECOa2BS0HZbqtIDvQkG1i61+5f3wNM=; b=Xwm15XBnX/3OwWxJTRHstWhuUXDpYUZ7cp6v4NPWPBmcXGqW1jfJNmu96gDcEjUBNp +VpYaWRwlaMebvK+EFMuriTLGKJorBZZbDsFB+YDo+Uo9OZYvWB2rWyPbPJ1nOSrpwzq a4kyY44aIxzA8SKzBNhPpMgJBalAyXClhVmG+GyfU2xu72U4QLQmtTwLGhre3vEf8eTj Z/e2IWOgu52bm8fvkkW5p9FJ85SE78CVpnCa++5SCf14OpBZOHdHIbbUpLJ61CEbup4B s8/uFE/SfZUOeJrFiqPbmJIvPrmZlMflhTwkCI0b73EkLJtXE6lvDQlC+Cm/jdxtLKv2 ylyQ== X-Gm-Message-State: APjAAAWqSahGOsRPbmfjvtegAbx1c4e2b7yzuDJQ0ugJd4PBszw5ODr5 2BtsGT0qRPTIeb7SONnLWdB7C3BpzjMdKV6jVrQ= X-Google-Smtp-Source: APXvYqwL/jgaAEmdpn1Ng+fk13R38W7lq9ZvR4wq6Lcg2fFDGB25Ji8orP5XnF8UEUOEObw6uPpOkoZkCLt5L9dVt80= X-Received: by 2002:a5e:8e4d:: with SMTP id r13mr33686661ioo.60.1582362355629; Sat, 22 Feb 2020 01:05:55 -0800 (PST) MIME-Version: 1.0 References: <20200131170201.3236153-1-jerinj@marvell.com> <8553959.CDJkKcVGEf@xps> <2267983.jE0xQCEvom@xps> In-Reply-To: <2267983.jE0xQCEvom@xps> From: Jerin Jacob Date: Sat, 22 Feb 2020 14:35:38 +0530 Message-ID: To: Thomas Monjalon Cc: Jerin Jacob , Ray Kinsella , dpdk-dev , Prasun Kapoor , Nithin Dabilpuram , Kiran Kumar K , Pavan Nikhilesh , Narayana Prasad , nsaxena@marvell.com, sshankarnara@marvell.com, Honnappa Nagarahalli , David Marchand , Ferruh Yigit , Andrew Rybchenko , Ajit Khaparde , "Ye, Xiaolong" , Raslan Darawsheh , Maxime Coquelin , Akhil Goyal , Cristian Dumitrescu , John McNamara , "Richardson, Bruce" , Anatoly Burakov , Gavin Hu , David Christensen , "Ananyev, Konstantin" , Pallavi Kadam , Olivier Matz , Gage Eads , "Rao, Nikhil" , Erik Gabriel Carrillo , Hemant Agrawal , "Artem V. Andreev" , Stephen Hemminger , Shahaf Shuler , "Wiles, Keith" , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , Jasvinder Singh , Vladimir Medvedkin , techboard@dpdk.org, Stephen Hemminger , dave@barachs.net Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [RFC PATCH 0/5] graph: introduce graph subsystem X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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, Feb 21, 2020 at 9:44 PM Thomas Monjalon wrote: > > 21/02/2020 16:56, Jerin Jacob: > > On Fri, Feb 21, 2020 at 4:40 PM Thomas Monjalon wrote: > > > 21/02/2020 11:30, Jerin Jacob: > > > > On Mon, Feb 17, 2020 at 4:28 PM Jerin Jacob wrote: > > > > > On Mon, Feb 17, 2020 at 2:08 PM Thomas Monjalon wrote: > > > > > > If we add rte_graph to DPDK, we will have 2 similar libraries. > > > > > > > > > > > > I already proposed several times to move rte_pipeline in a separate > > > > > > repository for two reasons: > > > > > > 1/ it is acting at a higher API layer level > > > > > > > > > > We need to define what is the higher layer API. Is it processing beyond L2? > > > > > > My opinion is that any API which is implemented differently > > > for different hardware should be in DPDK. > > > > We need to define SIMD optimization(not HW specific to but > > architecture-specific) > > treatment as well, as the graph and node library will have SIMD > > optimization as well. > > I think SIMD optimization is generic to any performance-related project, > not specific to DPDK. > > > > In general, by the above policy enforced, we need to split DPDK like below, > > dpdk.git > > ---------- > > librte_compressdev > > librte_bbdev > > librte_eventdev > > librte_pci > > librte_rawdev > > librte_eal > > librte_security > > librte_mempool > > librte_mbuf > > librte_cryptodev > > librte_ethdev > > > > other repo(s). > > ---------------- > > librte_cmdline > > librte_cfgfile > > librte_bitratestats > > librte_efd > > librte_latencystats > > librte_kvargs > > librte_jobstats > > librte_gso > > librte_gro > > librte_flow_classify > > librte_pipeline > > librte_net > > librte_metrics > > librte_meter > > librte_member > > librte_table > > librte_stack > > librte_sched > > librte_rib > > librte_reorder > > librte_rcu > > librte_power > > librte_distributor > > librte_bpf > > librte_ip_frag > > librte_hash > > librte_fib > > librte_timer > > librte_telemetry > > librte_port > > librte_pdump > > librte_kni > > librte_acl > > librte_vhost > > librte_ring > > librte_lpm > > librte_ipsec > > I think it is a fair conclusion of the scope I am arguing, yes. OK. See below. > > > What is expected to be maintained, tested, etc. > > > > We need to maintain and test other code in OTHER dpdk repo as well. > > Yes but the ones responsible are not the same. I see your point. Can I interpret it as you would like to NOT take responsibility of SW libraries(Items enumerated in the second list)? I think, the main question would be, how it will deliver to distros and/or end-users and what will be part of the dpdk release? I can think of two options. Maybe distro folks have better view on this. options 1: - Split dpdk to dpdk-core.git, dpdk-algo.git etc based on the functionalities and maintainer's availability. - Follow existing release cadence and deliver single release tarball with content from the above repos. options 2: - Introduce more subtrees(dpdk-next-algo.git etc) based on the functionalities and maintainer's availability. - Follow existing release cadence and have a pull request to main dpdk.git just like Linux kernel or existing scheme of things. I am for option 2. NOTE: This new graph and node library, I would like to make its new subtree in the existing scheme of things so that it will NOT be a burden for you to manage.