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 310C2A0557; Sat, 22 Feb 2020 10:53:04 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C61D11BFBE; Sat, 22 Feb 2020 10:53:02 +0100 (CET) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by dpdk.org (Postfix) with ESMTP id E1E351BFA5; Sat, 22 Feb 2020 10:53:00 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id EBAB17781; Sat, 22 Feb 2020 04:52:59 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sat, 22 Feb 2020 04:53:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=vb4xDdidbv1s9mrdGhxJVEAMiV4CcJdn2RT3/AT9HZc=; b=kiKeq10FYY0a +3VSwpFMZz2WP8SovJYLnxylklxD+GwCBMbtoQpzpZ5dqKx+ns9ZM65FSS0Q01Z7 oe1CJ0L9PMuUzNA6JvNRIzQ1yw3Vot67RdXGcwY2j6AMPyli4B41fuzEoslTD++S bivcNh6wH0iYd3GZNZ/VOJR/Q8JVHE8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=vb4xDdidbv1s9mrdGhxJVEAMiV4CcJdn2RT3/AT9H Zc=; b=XNj+VolTikL6tB3v3Yu6njyes8tQTcggBFo0jqY8jeIJ5zChIUhof/oKF p510PoGoePlfw8Mt2JyO3ScXFdkOSLv44M3py27QdcYVeKU0RynYyJryn92tOREt 5ZPDRDaaVr/2ey2BAHofA2CvSbSbn2la7OQxirfi0X/t79L0ATV0EubWHwmsWfpi 91LgOV3Z5HiXpskSx9vGAlblaXJWP23PYUIqj2NBAK4D1yW8YEN7f3PbnqNFoFPq bE+nQB1q2JiNff0q8oWiGiNizbGx4W6qvTIGzXCVRR+JY3dGM76Ja2CZDLd/qOVx VVcguWkgCJWewOYCXp6STi39WREPg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkeeigddtlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id C81443060BD1; Sat, 22 Feb 2020 04:52:53 -0500 (EST) From: Thomas Monjalon To: Jerin Jacob 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" , Mattias =?ISO-8859-1?Q?R=F6nnblom?= , Jasvinder Singh , Vladimir Medvedkin , techboard@dpdk.org, Stephen Hemminger , dave@barachs.net Date: Sat, 22 Feb 2020 10:52:52 +0100 Message-ID: <2469664.Isy0gbHreE@xps> In-Reply-To: References: <20200131170201.3236153-1-jerinj@marvell.com> <2267983.jE0xQCEvom@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 22/02/2020 10:05, Jerin Jacob: > 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)? It's not only about me. This is a community decision. > 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. The option 2 is to make maintainers life easier. Keeping all libraries in the same repository allows to have an unique release and a central place for the apps and docs. The option 1 may make contributors life easier if we consider adding new libraries can make contributions harder in case of dependencies. The option 1 makes also repositories smaller, so maybe easier to approach. It makes easier to fully validate testing and quality of a repository. Having separate packages makes easier to select what is distributed and supported. After years thinking about the scope of DPDK repository, I am still not sure which solution is best. I really would like to see more opinions, thanks.