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 EB960A0525; Fri, 21 Feb 2020 11:30:35 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 242141BFAD; Fri, 21 Feb 2020 11:30:35 +0100 (CET) Received: from mail-il1-f194.google.com (mail-il1-f194.google.com [209.85.166.194]) by dpdk.org (Postfix) with ESMTP id 2DD0037B0; Fri, 21 Feb 2020 11:30:33 +0100 (CET) Received: by mail-il1-f194.google.com with SMTP id i7so1235230ilr.7; Fri, 21 Feb 2020 02:30:33 -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=yaVbSIIsqJ5yff2CpYkFRW9hunk05VxJGctZYpWTWso=; b=pj/rh6gi3Wq+doEPh20e1fLmcLlbTIFO04gS+b8x1/9o4aUDh/1YwicB3rNk37+1Mw GUTT8TQ7ZIIlscacH2kqqTKbbs5AU8Gnyb024xu7xPeC0ast9EhoRWsAiF3LlDMrYQyH nXdoRRj/ikN7LUa9D/Hwfhp3R557Vo9CUFmQOCYosfjbD9dwiIxkBbyRrGTlGZJ2d3nm D/IAyGnqY5Z9dFs/0HaszQ6gCtxj4Q2/3nFh0Bnw0uKzkwu7ZTVMZIlzFFHxf8UEYR7R cwxuee8KZVdoxvoGNsCtFo5S3KuBGOl05BU0jzSHYeFtXbaMmePb9hZWvIKvrywl6FjM Mvvw== 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=yaVbSIIsqJ5yff2CpYkFRW9hunk05VxJGctZYpWTWso=; b=suZxVnsemCA/NCCog+x0EH/0MQlEO7ETg2ad5UqkXz24/ZA8V7BDxxS6H590UmHYG1 lamjhopKrSb+KskDHLNHTxlMTMf3aBk8cd0MjkOZU55a2x9ddB4vVpk8FeXuQBYBcDVk UU/Pt7M+F2gYAagjzLv+IDOfEr0aEAsD2kX6NfKZJx4PLRDYb/SraHbfFq5GE4uOccpl qfLro6+kSkZtH/h4s2IdNDwwYt0bYfTtg3o5qDIam4yrZwKrjtZB2ljnxYWIUY7E6jxa /630qpk9Su1NpjhkCV+JNp2rwSoRe6PLaXLZifqpo3DUddbrh4290AdTDX17NxV58OEC 1MgA== X-Gm-Message-State: APjAAAWVobSn65h6OM602eAr+fU6nbglasm4PlkQ+uzOKYYIkVybRQzp Wrqh27YKLLV/pRlB8NKPRXjROVsPBYb6jzYHRJwIKG78+85LWg== X-Google-Smtp-Source: APXvYqyFa/ise09GJmGEtOV6mxmBX2gLfeAs+l2O6KsL7S84J8LUDK1L5uMFqSipl95ewPqZoQxGPt+W+sM0DFClcvI= X-Received: by 2002:a05:6e02:f47:: with SMTP id y7mr36299690ilj.162.1582281032265; Fri, 21 Feb 2020 02:30:32 -0800 (PST) MIME-Version: 1.0 References: <20200131170201.3236153-1-jerinj@marvell.com> <5381669.peFUeoqG7q@xps> In-Reply-To: From: Jerin Jacob Date: Fri, 21 Feb 2020 16:00:16 +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 Mon, Feb 17, 2020 at 4:28 PM Jerin Jacob wrote: > > On Mon, Feb 17, 2020 at 2:08 PM Thomas Monjalon wrote: > > > > Hi Jerin, > > Hi Thomas, > > 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. If there no consensus in the email, I would like to propose this topic to the 26th Feb TB meeting. > > > > > 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? > > 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? > > > > 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 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? > > 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? > > 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. > > > >