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 1BCB1A0525; Fri, 21 Feb 2020 17:50:10 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E48321BFCE; Fri, 21 Feb 2020 17:49:31 +0100 (CET) Received: from gateway20.websitewelcome.com (gateway20.websitewelcome.com [192.185.46.107]) by dpdk.org (Postfix) with ESMTP id 04E7B34F3 for ; Fri, 21 Feb 2020 16:53:25 +0100 (CET) Received: from cm14.websitewelcome.com (cm14.websitewelcome.com [100.42.49.7]) by gateway20.websitewelcome.com (Postfix) with ESMTP id 1022D400CE16F for ; Fri, 21 Feb 2020 08:39:21 -0600 (CST) Received: from gator4196.hostgator.com ([108.167.189.21]) by cmsmtp with SMTP id 5AcHj7t3EXVkQ5AcHjUDaG; Fri, 21 Feb 2020 09:53:25 -0600 X-Authority-Reason: nr=8 Received: from [173.38.117.84] (port=5455 helo=Win10) by gator4196.hostgator.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1j5AcF-000kXR-PT; Fri, 21 Feb 2020 09:53:23 -0600 From: To: =?utf-8?Q?'Mattias_R=C3=B6nnblom'?= , "'Thomas Monjalon'" , "'Jerin Jacob'" Cc: "'Jerin Jacob'" , "'Ray Kinsella'" , "'dpdk-dev'" , "'Prasun Kapoor'" , "'Nithin Dabilpuram'" , "'Kiran Kumar K'" , "'Pavan Nikhilesh'" , "'Narayana Prasad'" , , , "'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'" , "'Jasvinder Singh'" , "'Vladimir Medvedkin'" , , "'Stephen Hemminger'" References: <20200131170201.3236153-1-jerinj@marvell.com> <8553959.CDJkKcVGEf@xps> <2433be82-b18a-3de2-35aa-35a5d06d481c@ericsson.com> In-Reply-To: <2433be82-b18a-3de2-35aa-35a5d06d481c@ericsson.com> Date: Fri, 21 Feb 2020 10:53:18 -0500 Message-ID: <001d01d5e8cf$0bd6abb0$23840310$@barachs.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIYfBRA1cLv9oVONNuCbDmRejKkfAJhz89QAnXeHWwB6gslGgMtq6Arp1EnVBA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4196.hostgator.com X-AntiAbuse: Original Domain - dpdk.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - barachs.net X-BWhitelist: no X-Source-IP: 173.38.117.84 X-Source-L: No X-Exim-ID: 1j5AcF-000kXR-PT X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (Win10) [173.38.117.84]:5455 X-Source-Auth: dave@barachs.net X-Email-Count: 36 X-Source-Cap: ZGJhcmFjaDtkYmFyYWNoO2dhdG9yNDE5Ni5ob3N0Z2F0b3IuY29t X-Local-Domain: yes X-Mailman-Approved-At: Fri, 21 Feb 2020 17:49:22 +0100 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" I can share a data-point with respect to constructing a reasonably = functional network stack. Original work on the project which eventually = became fd.io vpp started in 2002. I've worked on the vpp code base = full-time for 18 years. In terms of lines of code: the vpp graph subsystem is a minuscule = fraction of the project as a whole. We've rewritten performance-critical = bits of the vpp netstack multiple times. FWIW... Dave =20 -----Original Message----- From: Mattias R=C3=B6nnblom =20 Sent: Friday, February 21, 2020 10:39 AM To: Thomas Monjalon ; 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 ; Jasvinder Singh = ; Vladimir Medvedkin = ; techboard@dpdk.org; Stephen Hemminger = ; dave@barachs.net Subject: Re: [dpdk-dev] [RFC PATCH 0/5] graph: introduce graph subsystem On 2020-02-21 12:10, 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: >>> Thanks for starting this discussion now. It is an interesting=20 >>> discussion. Some thoughts below. >>> We can decide based on community consensus and follow a single rule=20 >>> 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=20 >> 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=20 > 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. > If you assume the capability of networking hardware will grow, and you = want to unify different networking hardware with varying capabilities = (and also include software-only implementations) under one API, then you = might well end up growing DPDK into the software stack you mention = below. Soft implementations of complex protocols will require operating = system-like support services like timers, RCU, various lock-less data = structures, deferred work mechanism, counter handling frameworks, = control plane interfaces, etc. Coupling should always be avoided of = course, but DPDK would inevitably no longer be a pick-and-choose = sm=C3=B6rg=C3=A5sbord library - at least as long as the consumer wants = to utilize this higher-layer functionality. This would make DPDK more of a packet processing run-time or a = special-purpose, networking operating system than the "a bunch of = Ethernet drivers in user space" as it started out as. I'm not saying that's a bad thing. In fact, I think it sounds like an = interesting option, although also a very challenging one. From what I = can see, DPDK has already set out along this route already. If this is a = conscious decision or not, I don't know. Add to this, if Linux expands = further with AF_XDP-like features, beyond simply packet I/O, it might = not only try to take over DPDK's original concerns, but also more of the = current ones. >>> 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=20 >>> ethdev and it is under lib/lib_node/ >>> >>> >>> Another interesting question would what would be an issue in DPDK=20 >>> supporting beyond L2. Or higher level protocols? > Definitely higher than L2 is OK in DPDK as long as it is related to=20 > 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=20 >>>> separate repository, and welcome rte_graph as well in another=20 >>>> separate repository. >>> What would be gain out of this? > The gain is to be clear about what should be the focus for=20 > 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.=20 >>> Internally, it can be two different repo but release needs to go=20 >>> through one repo. >>> >>> If we are focusing ONLY on the driver API then how can DPDK grow=20 >>> further? If linux kernel would be thought only have just the kernel=20 >>> 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=20 >>>> 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=20 >>> abstraction may not be enough abstract the difference in HW. The=20 >>> 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. > >