From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 28452A0471 for ; Mon, 17 Jun 2019 15:23:55 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EE3171BEDC; Mon, 17 Jun 2019 15:23:53 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by dpdk.org (Postfix) with ESMTP id E021D1BEA4 for ; Mon, 17 Jun 2019 15:23:52 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 6168E40007 for ; Mon, 17 Jun 2019 15:23:52 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 4F5D940011; Mon, 17 Jun 2019 15:23:52 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.4.1 X-Spam-Score: -0.9 Received: from [192.168.1.59] (host-90-232-200-177.mobileonline.telia.com [90.232.200.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id A341A40007; Mon, 17 Jun 2019 15:23:49 +0200 (CEST) To: Anoob Joseph , Jerin Jacob Kollanukkaran , Nikhil Rao , Erik Gabriel Carrillo , Abhinandan Gujjar , Bruce Richardson , Pablo de Lara Cc: Narayana Prasad Raju Athreya , "dev@dpdk.org" , Lukas Bartosik , Pavan Nikhilesh Bhagavatula , Hemant Agrawal , Nipun Gupta , Harry van Haaren , Liang Ma References: <1559583160-13944-1-git-send-email-anoobj@marvell.com> From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= Message-ID: <7093263b-ff3d-fe84-18fb-43535a959276@ericsson.com> Date: Mon, 17 Jun 2019 15:23:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper library 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 2019-06-14 11:18, Anoob Joseph wrote: > Hi Mattias, > >> A more extensive description of the purpose of the eventmode helper >> library would be helpful. >> >> Is this supposed to be a generic framework for real-world >> applications, or only something to simplify DPDK the implementation of >> DPDK example programs and similar? > > This is intended as a generic framework, but the initial targets would be limited to DPDK example applications. > > For any application to use an event device for dynamic load balancing, it has to configure the event device and the adapters. Configuring the adapters would involve providing various parameters based on which the dynamic scheduling should happen. But requiring the application to do all this configuration would make the application complicated as well as the same code has to be repeated for a new application. Event mode helper tries to solve that. > > All the complex configuration would be implemented by the helper library and the helper library would provide a default conf as well. > The task of configuring eventdev and its adaptors, and ethernet devices is a daunting task indeed. If we could simplify that, that would be great. However, the flexibility and many of the parameters are there for a reason (those there aren't should be deprecated). I would expect a real-world application to tweak quite a few of them. I know our applications do. I worry I have is that if you put eventmode (in its current form) forward as a generic framework, applications might start using it, only to realize it's not flexible enough, and then eventmode is just an extra layer, increasing rather than reducing complexity. Or even worse, the application's developers are forced to do a big-bang switch over to using the event and ethernet device APIs directly, in case they can't patch DPDK to work around the eventmode-assumption-that-didn't-hold-for-them. You could always add flexibility to the framework (as you encounter a need for it), but then it will grow in complexity as well. A less ambitious approach would be to instead do a properly modularized, non-trivial eventdev example application, for the applications to start off from, instead of a generic library. I would expect it to be very difficult to design a truly generic application framework for eventdev-based applications. Such a framework would tie everything that's needed in a non-trivial application together. If successful, it would be a huge step toward making DPDK an operating system for packet processing applications. What event devices have you tested with?