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 D31E5A0524; Mon, 24 Feb 2020 12:00:00 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 283331BFA5; Mon, 24 Feb 2020 12:00:00 +0100 (CET) Received: from relay0225.mxlogin.com (relay0225.mxlogin.com [199.181.239.225]) by dpdk.org (Postfix) with ESMTP id CD1391BE85 for ; Mon, 24 Feb 2020 11:59:57 +0100 (CET) Received: from filter004.mxroute.com ([149.28.56.236] 149.28.56.236.vultr.com) (Authenticated sender: mN4UYu2MZsgR) by relay0225.mxlogin.com (ZoneMTA) with ESMTPSA id 17076da80c7000c6c5.006 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Mon, 24 Feb 2020 10:59:56 +0000 X-Zone-Loop: c11929cf31d3f562a5e606a0d6a507bb97f73ffb3948 X-Originating-IP: [149.28.56.236] Received: from galaxy.mxroute.com (unknown [23.92.70.113]) by filter004.mxroute.com (Postfix) with ESMTPS id AE9C73ED98; Mon, 24 Feb 2020 10:59:54 +0000 (UTC) Received: from [192.198.151.43] by galaxy.mxroute.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1j6B7u-000227-No; Mon, 24 Feb 2020 05:38:14 -0500 To: Jerin Jacob , Thomas Monjalon Cc: Jerin Jacob , 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 References: <20200131170201.3236153-1-jerinj@marvell.com> <2267983.jE0xQCEvom@xps> <2469664.Isy0gbHreE@xps> From: Ray Kinsella Autocrypt: addr=mdr@ashroe.eu; keydata= mQINBFv8B3wBEAC+5ImcgbIvadt3axrTnt7Sxch3FsmWTTomXfB8YiuHT8KL8L/bFRQSL1f6 ASCHu3M89EjYazlY+vJUWLr0BhK5t/YI7bQzrOuYrl9K94vlLwzD19s/zB/g5YGGR5plJr0s JtJsFGEvF9LL3e+FKMRXveQxBB8A51nAHfwG0WSyx53d61DYz7lp4/Y4RagxaJoHp9lakn8j HV2N6rrnF+qt5ukj5SbbKWSzGg5HQF2t0QQ5tzWhCAKTfcPlnP0GymTBfNMGOReWivi3Qqzr S51Xo7hoGujUgNAM41sxpxmhx8xSwcQ5WzmxgAhJ/StNV9cb3HWIoE5StCwQ4uXOLplZNGnS uxNdegvKB95NHZjRVRChg/uMTGpg9PqYbTIFoPXjuk27sxZLRJRrueg4tLbb3HM39CJwSB++ YICcqf2N+GVD48STfcIlpp12/HI+EcDSThzfWFhaHDC0hyirHxJyHXjnZ8bUexI/5zATn/ux TpMbc/vicJxeN+qfaVqPkCbkS71cHKuPluM3jE8aNCIBNQY1/j87k5ELzg3qaesLo2n1krBH bKvFfAmQuUuJT84/IqfdVtrSCTabvDuNBDpYBV0dGbTwaRfE7i+LiJJclUr8lOvHUpJ4Y6a5 0cxEPxm498G12Z3NoY/mP5soItPIPtLR0rA0fage44zSPwp6cQARAQABtBxSYXkgS2luc2Vs bGEgPG1kckBhc2hyb2UuZXU+iQJUBBMBCAA+FiEEcDUDlKDJaDuJlfZfdJdaH/sCCpsFAlv8 B3wCGyMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQdJdaH/sCCptdtRAAl0oE msa+djBVYLIsax+0f8acidtWg2l9f7kc2hEjp9h9aZCpPchQvhhemtew/nKavik3RSnLTAyn B3C/0GNlmvI1l5PFROOgPZwz4xhJKGN7jOsRrbkJa23a8ly5UXwF3Vqnlny7D3z+7cu1qq/f VRK8qFyWkAb+xgqeZ/hTcbJUWtW+l5Zb+68WGEp8hB7TuJLEWb4+VKgHTpQ4vElYj8H3Z94a 04s2PJMbLIZSgmKDASnyrKY0CzTpPXx5rSJ1q+B1FCsfepHLqt3vKSALa3ld6bJ8fSJtDUJ7 JLiU8dFZrywgDIVme01jPbjJtUScW6jONLvhI8Z2sheR71UoKqGomMHNQpZ03ViVWBEALzEt TcjWgJFn8yAmxqM4nBnZ+hE3LbMo34KCHJD4eg18ojDt3s9VrDLa+V9fNxUHPSib9FD9UX/1 +nGfU/ZABmiTuUDM7WZdXri7HaMpzDRJUKI6b+/uunF8xH/h/MHW16VuMzgI5dkOKKv1LejD dT5mA4R+2zBS+GsM0oa2hUeX9E5WwjaDzXtVDg6kYq8YvEd+m0z3M4e6diFeLS77/sAOgaYL 92UcoKD+Beym/fVuC6/55a0e12ksTmgk5/ZoEdoNQLlVgd2INtvnO+0k5BJcn66ZjKn3GbEC VqFbrnv1GnA58nEInRCTzR1k26h9nmS5Ag0EW/wHfAEQAMth1vHr3fOZkVOPfod3M6DkQir5 xJvUW5EHgYUjYCPIa2qzgIVVuLDqZgSCCinyooG5dUJONVHj3nCbITCpJp4eB3PI84RPfDcC hf/V34N/Gx5mTeoymSZDBmXT8YtvV/uJvn+LvHLO4ZJdvq5ZxmDyxfXFmkm3/lLw0+rrNdK5 pt6OnVlCqEU9tcDBezjUwDtOahyV20XqxtUttN4kQWbDRkhT+HrA9WN9l2HX91yEYC+zmF1S OhBqRoTPLrR6g4sCWgFywqztpvZWhyIicJipnjac7qL/wRS+wrWfsYy6qWLIV80beN7yoa6v ccnuy4pu2uiuhk9/edtlmFE4dNdoRf7843CV9k1yRASTlmPkU59n0TJbw+okTa9fbbQgbIb1 pWsAuicRHyLUIUz4f6kPgdgty2FgTKuPuIzJd1s8s6p2aC1qo+Obm2gnBTduB+/n1Jw+vKpt 07d+CKEKu4CWwvZZ8ktJJLeofi4hMupTYiq+oMzqH+V1k6QgNm0Da489gXllU+3EFC6W1qKj tkvQzg2rYoWeYD1Qn8iXcO4Fpk6wzylclvatBMddVlQ6qrYeTmSbCsk+m2KVrz5vIyja0o5Y yfeN29s9emXnikmNfv/dA5fpi8XCANNnz3zOfA93DOB9DBf0TQ2/OrSPGjB3op7RCfoPBZ7u AjJ9dM7VABEBAAGJAjwEGAEIACYWIQRwNQOUoMloO4mV9l90l1of+wIKmwUCW/wHfAIbDAUJ CWYBgAAKCRB0l1of+wIKm3KlD/9w/LOG5rtgtCUWPl4B3pZvGpNym6XdK8cop9saOnE85zWf u+sKWCrxNgYkYP7aZrYMPwqDvilxhbTsIJl5HhPgpTO1b0i+c0n1Tij3EElj5UCg3q8mEc17 c+5jRrY3oz77g7E3oPftAjaq1ybbXjY4K32o3JHFR6I8wX3m9wJZJe1+Y+UVrrjY65gZFxcA thNVnWKErarVQGjeNgHV4N1uF3pIx3kT1N4GSnxhoz4Bki91kvkbBhUgYfNflGURfZT3wIKK +d50jd7kqRouXUCzTdzmDh7jnYrcEFM4nvyaYu0JjSS5R672d9SK5LVIfWmoUGzqD4AVmUW8 pcv461+PXchuS8+zpltR9zajl72Q3ymlT4BTAQOlCWkD0snBoKNUB5d2EXPNV13nA0qlm4U2 GpROfJMQXjV6fyYRvttKYfM5xYKgRgtP0z5lTAbsjg9WFKq0Fndh7kUlmHjuAIwKIV4Tzo75 QO2zC0/NTaTjmrtiXhP+vkC4pcrOGNsbHuaqvsc/ZZ0siXyYsqbctj/sCd8ka2r94u+c7o4l BGaAm+FtwAfEAkXHu4y5Phuv2IRR+x1wTey1U1RaEPgN8xq0LQ1OitX4t2mQwjdPihZQBCnZ wzOrkbzlJMNrMKJpEgulmxAHmYJKgvZHXZXtLJSejFjR0GdHJcL5rwVOMWB8cg== Message-ID: <07f2b616-2475-4a08-93f7-4a2189908e7b@ashroe.eu> Date: Mon, 24 Feb 2020 10:59:45 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-AuthUser: mdr@ashroe.eu 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 22/02/2020 10:24, Jerin Jacob wrote: > On Sat, Feb 22, 2020 at 3:23 PM Thomas Monjalon wrote: >> >> 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. > > OK. Let wait for community feedback. > Probably we discuss more in public TB meeting in 26th Feb. > >> >> >>> 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. > > If the final dpdk release tarball looks same for option1 and option2 > then I think, > option 1 is overhead to manage intra repo dependency. > > I agree with Thomas, it is better to decide as a community what > direction we need > to take and align existing and new libraries with that scheme. > +1 to Option 2. As Jerin points out, it has allowed other larger communities to scale effectively. > >> >> 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. > > Yes. > >> >>