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 3DDE3A0553; Mon, 17 Feb 2020 11:58:59 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id F02E11DAEF; Mon, 17 Feb 2020 11:58:57 +0100 (CET) Received: from mail-il1-f193.google.com (mail-il1-f193.google.com [209.85.166.193]) by dpdk.org (Postfix) with ESMTP id 547581DAED; Mon, 17 Feb 2020 11:58:56 +0100 (CET) Received: by mail-il1-f193.google.com with SMTP id v13so13878014iln.4; Mon, 17 Feb 2020 02:58: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=u3LYRVBvAeq1dT5+u2mFhxil891+RFocJBNocvE34iU=; b=stz0REbXdCOJtsuh/yi4DafHsNdHabZy5pBJm93tMmx2Fj34JaY7ac6PDnaoh1NO35 7fCcpWrNk0s8sWSYWWfhRtHciX0R+OirPtm2oi9pHBQnDjQmaex2LcV1sv3QTTf60dS/ sEBoCbJl2OL1KfnsKIza7nr3Li02CIlOw/9e46kemvwRBoIFZqLVgeDPGO6JavpgMz3m p+fz+5KnX0iopIk0LSdAULgRUD5uZRRamC9VRP2Nt6FUlF8ezGbBfWyzCvjyS/IQRsmt hgR9ReskpDfHdbSVV6kDZKdUhj0clThtXv51nWrGIu3R18EVZYt4/DwhrZTJuVXi2ve9 EM8g== 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=u3LYRVBvAeq1dT5+u2mFhxil891+RFocJBNocvE34iU=; b=g8Vtzl+A1A+5tJKYCBG776dYjrAIGLS4pXrl/XamcXBg5NpSkSmUOuyqM7v6rV+Sjc h6bgnZ3yFjrtucHOb+xELW8g9+2QcdlY2GdZmCYj0hhuQvpy5XEEUZCmShtu7jWGAVsn SmK3OWatAVoHGrTBM2sX5QB9ohWSsnMrks+k7AcYudS7LRIAxCxAjzmmSh1gi9oF2/Hr awVk/9pu0dH8aHTaPfRohzEBuwMXS73VtimcqRyprDawlBOFngJ9BXQcdN7UQ4p48Wjr F9gccujjqcM3I+9zACm2ZhCjd116gzjAn7odzu8CkBVgeOGpki8VYfpDp0mOc/b50aYZ Rsnw== X-Gm-Message-State: APjAAAV4eL7IYssp2UcsyeayQsxzMgnTmUVeEHm/+j6ybP7/KBihpYWM MlREx+L+LEb7IOvWO7EJrg6LC2A/qoQbUu2kppo= X-Google-Smtp-Source: APXvYqyloprzEfD9rkei0AqvyYPON29O2tHrFlIjS7rb4vpHqHVpuJCJcebmmTWheOZdWgRw4n+6Ar8tnTKkb4H8NTE= X-Received: by 2002:a92:50a:: with SMTP id q10mr14879291ile.294.1581937135205; Mon, 17 Feb 2020 02:58:55 -0800 (PST) MIME-Version: 1.0 References: <20200131170201.3236153-1-jerinj@marvell.com> <5381669.peFUeoqG7q@xps> In-Reply-To: <5381669.peFUeoqG7q@xps> From: Jerin Jacob Date: Mon, 17 Feb 2020 16:28: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 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. > > 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. > >