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 BB219A0525; Fri, 21 Feb 2020 12:10:36 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 758581BFAC; Fri, 21 Feb 2020 12:10:35 +0100 (CET) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by dpdk.org (Postfix) with ESMTP id 36B3B34F3; Fri, 21 Feb 2020 12:10:33 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 529A46D47; Fri, 21 Feb 2020 06:10:32 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 21 Feb 2020 06:10:32 -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=L1CUgF/C4w9UCpEOobuY2XfD0WsoYwmX8RejColBAPM=; b=mhCl5ivHAbWL AsjGLAQkDNwGzuYepmR4TFiGXdLTzfxesyfCADpgB3nUKUvib8BhM7++IsNFdHpu gberEM5i4fXs38HFbEoFLxrzd7PC7VFHThmgytSGeFPnRffe0DzehoHPTABVG6kZ fjAY5OCDWwPjUjv0z2Gc+XSsUC4vhWY= 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=L1CUgF/C4w9UCpEOobuY2XfD0WsoYwmX8RejColBA PM=; b=X3MFJ0Ah+YVVv76dQsfzaz3VOZA6G1ZiXG7UCzShRryR0n8G8QWuY237V EmSZHEI3y8yW0wQPOyiBTpUmwX8vcku5z7KPxZcQTl/fBxyPUIP1kDWmGcHUrldO O0weG4HbQmefrJxFKns5dnzk1oZWcppHcmcId6bKql1K0Gh2NnZu1dn6oCCwahCn WPZZTnh5JvtbAjlCZkyZI6YmYxK8Sa79DsC3dB+chYwtDchhRnuVSUsoT1MTgdU4 ZtYefxuB4HP6bFCLtVJchFsZOonc5vu0BAiwS3yJ7+057GQHyIgFtz87hAeGhJVL quTnTNovbuYkr40hUPsZ09yCOOnQw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkeeggddvfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddvtdehrdeiledrgeelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (49.69.205.77.rev.sfr.net [77.205.69.49]) by mail.messagingengine.com (Postfix) with ESMTPA id 4DDBC328005A; Fri, 21 Feb 2020 06:10:20 -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: Fri, 21 Feb 2020 12:10:15 +0100 Message-ID: <8553959.CDJkKcVGEf@xps> In-Reply-To: References: <20200131170201.3236153-1-jerinj@marvell.com> 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" 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: > > Thanks for starting this discussion now. It is an interesting > > discussion. Some thoughts below. > > We can decide based on community consensus and follow a single rule > > across the components. > > Thomas, > > No feedback yet on the below questions. Indeed. I was waiting for opininons from others. > If there no consensus in the email, I would like to propose this topic > to the 26th Feb TB meeting. I gave my opinion below. If a consensus cannot be reached, I agree with the request to the techboard. > > > 17/02/2020 08:19, Jerin Jacob: > > > > I got initial comments from Ray and Stephen on this RFC[1]. Thanks for > > > > the comments. > > > > > > > > Is anyone else planning to have an architecture level or API usage > > > > level review or any review of other top-level aspects? > > > > > > 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. Hardware devices can offload protocol processing higher than L2, so L2 does not look to be a good limit from my point of view. > > In the context of Graph library, it is a framework, not using any of > > the substem API > > other than EAL and it is under lib/librte_graph. > > Nodes library using graph and other subsystem components such as ethdev and > > it is under lib/lib_node/ > > > > > > Another interesting question would what would be an issue in DPDK supporting > > beyond L2. Or higher level protocols? Definitely higher than L2 is OK in DPDK as long as it is related to hardware capabilities, not software stack (which can be a DPDK application). > > > 2/ there can be different solutions in this layer > > > > Is there any issue with that? > > There is overlap with the distributor library and eventdev as well. > > ethdev and SW traffic manager libraries as well. That list goes on. I don't know how much it is an issue. But I think it shows that at least one implementation is not generic enough. > > > I think 1/ was commonly agreed in the community. > > > Now we see one more proof of the reason 2/. > > > > > > I believe it is time to move rte_pipeline (Packet Framework) > > > in a separate repository, and welcome rte_graph as well in another > > > separate repository. > > > > What would be gain out of this? The gain is to be clear about what should be the focus for contributors working on the main DPDK repository. What is expected to be maintained, tested, etc. > > My concerns are: > > # Like packet-gen, The new code will be filled with unnecessary DPDK > > version checks > > and unnecessary compatibility issues. > > # Anything is not in main dpdk repo, it is a second class citizen. > > # Customer has the pain to use two repos and two releases. Internally, > > it can be two different > > repo but release needs to go through one repo. > > > > If we are focusing ONLY on the driver API then how can DPDK grow > > further? If linux kernel > > would be thought only have just the kernel and networking/storage as > > different repo it would > > not have grown up? Linux kernel is selecting what can enter in the focus or not. And I wonder what is the desire of extending/growing the scope of a library? > > What is the real concern? Maintenance? > > > > > I think the original DPDK repository should focus on low-level features > > > which offer hardware offloads and optimizations. > > > > The nodes can be vendor-specific to optimize the specific use cases. > > As I mentioned in the cover letter, > > > > " > > 2) Based on our experience, NPU HW accelerates are so different than one vendor > > to another vendor. Going forward, We believe, API abstraction may not be enough > > abstract the difference in HW. The Vendor-specific nodes can abstract the HW > > differences and reuse generic the nodes as needed. > > This would help both the silicon vendors and DPDK end users. > > " > > > > Thoughts from other folks? > > > > > > > Consuming the low-level API in different abstractions, > > > and building applications, should be done on top of dpdk.git.