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 BE20BA0487 for ; Wed, 3 Jul 2019 11:38:16 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9D5891B954; Wed, 3 Jul 2019 11:38:15 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id 48B641B4B6; Wed, 3 Jul 2019 11:38:14 +0200 (CEST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x639cCI8001783; Wed, 3 Jul 2019 02:38:13 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pfpt0818; bh=y0KJ4byjewT3miUIPe5oBOKHSki4oJWmGSF/cR8oRBE=; b=OgUm6jyE0IzDcgYOF4bfE1Y6rYHxcWZin/y1YscDNo4V402J+4g4K2mllc9V3Pk0Ygxb BBHNa9dFYJVFzsQcJp8bp+u5cTRnjXO3QJTwPy3FZw0SQQCQd9VzkeFVxDm4aMeVOmRQ k/BT0+qFW8l4K/9QS7Gy66ag0csv4vh0upat3HDwLzXeB9VaToc5EJmmmAIBSc/ijcRJ lBgjfeLmGl4Y2TvDpEasrY7kv81/2sHpNl3KrQtv20vNVhPUXhm3PJGHpeJgZYs4aLhX kPWcHt3871Acq5wCVJijxjPZJR0fCi8iSi3I8cKf9PrWefIwb1RmNkv6s1IP0LD7TAMS /Q== Received: from sc-exch03.marvell.com ([199.233.58.183]) by mx0b-0016f401.pphosted.com with ESMTP id 2tg5734r8n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 03 Jul 2019 02:38:13 -0700 Received: from SC-EXCH01.marvell.com (10.93.176.81) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 3 Jul 2019 02:37:46 -0700 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (104.47.32.59) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Wed, 3 Jul 2019 02:37:46 -0700 ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=jvlRzxpKDNXH8BWh+6IwNMnQedV+Qn1naoT0XN5IxYGTM6D+gLzSSwVbiLEV+IpvlwJ1+KSqvmutwCj0D6NISJ5Lqw1C3W8WEL7badAzg7ERYAty+8VUz2SZIuT5YvjZNN0wt4U0tDULb0CtDifQfneqM/jmchosM5A9rDFavIM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y0KJ4byjewT3miUIPe5oBOKHSki4oJWmGSF/cR8oRBE=; b=AvwLMIDZMNbmYmWOwuwIKwsrC4j4hNj9lPBzl24YccPgcpr2v1J04f5fUuZAW+hze3b4nvx687dB/uGR5t+Rn10PtmtSSZp6INhN/LiodYYsk0dDN39eVbRkWCWPFfhSeh20oJKSi0Gxp97UFztqoHwNBZCsj7iwtdq+8Nv5t7o= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector2-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y0KJ4byjewT3miUIPe5oBOKHSki4oJWmGSF/cR8oRBE=; b=SFJn0ESi8tNPrIl9pLvHN5W1ELzwfCfthLTg12G54zV5msicYGb3mnoRChiahER3Zew9N8f/UYJOoZU7X4t62FqsVk7bdj9NTz0yZsjFNYNL3uRl8Rdv/ZbK+ddZdnHFT58PlL8SPc7MiyxHQii4uRFrwTmW55sIfY3xtumBzYY= Received: from MN2PR18MB2877.namprd18.prod.outlook.com (20.179.20.218) by MN2PR18MB3118.namprd18.prod.outlook.com (10.255.86.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.17; Wed, 3 Jul 2019 09:37:45 +0000 Received: from MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::595e:3b6c:3d12:7285]) by MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::595e:3b6c:3d12:7285%7]) with mapi id 15.20.2032.019; Wed, 3 Jul 2019 09:37:45 +0000 From: Anoob Joseph To: Thomas Monjalon CC: =?iso-8859-1?Q?Mattias_R=F6nnblom?= , "Bruce Richardson" , Jerin Jacob Kollanukkaran , "dev@dpdk.org" , Nikhil Rao , Erik Gabriel Carrillo , Abhinandan Gujjar , Pablo de Lara , Narayana Prasad Raju Athreya , Lukas Bartosik , "Pavan Nikhilesh Bhagavatula" , Hemant Agrawal , Nipun Gupta , Harry van Haaren , Liang Ma , "techboard@dpdk.org" Thread-Topic: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper library Thread-Index: AQHVMODfJaWShYqkoEST+UIrk446laa3YooAgAAIhgCAAAcs8IAAJdsAgAB+fuCAAIClAIAABBeQ Date: Wed, 3 Jul 2019 09:37:44 +0000 Message-ID: References: <27d46871-fa0c-1144-b7fa-8c57154478b3@ericsson.com> <1729509.9S1lrLiWIz@xps> In-Reply-To: <1729509.9S1lrLiWIz@xps> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [115.113.156.2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 85a3a743-bacc-44bf-700d-08d6ff9a1a48 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR18MB3118; x-ms-traffictypediagnostic: MN2PR18MB3118: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(376002)(396003)(39860400002)(136003)(51444003)(13464003)(189003)(199004)(966005)(68736007)(8936002)(25786009)(6306002)(9686003)(14444005)(86362001)(6436002)(316002)(55016002)(66066001)(81166006)(4326008)(256004)(7416002)(6916009)(478600001)(54906003)(99286004)(8676002)(81156014)(446003)(71200400001)(14454004)(71190400001)(11346002)(561944003)(3846002)(66476007)(33656002)(66556008)(486006)(53936002)(6246003)(476003)(6116002)(30864003)(5660300002)(102836004)(7736002)(229853002)(64756008)(66946007)(73956011)(53546011)(305945005)(186003)(66446008)(2906002)(52536014)(26005)(76116006)(66574012)(74316002)(76176011)(55236004)(6506007)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR18MB3118; H:MN2PR18MB2877.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: marvell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: UyJgp2lY2yK8+n3xF0Fe/8pM73DRGM/DQLdKaDjgVdU67jT8Cm8z41HIP9BYDlapZ2YZebz6kAXGoxQlphJHBsBGujh3AhPV7IDTMy6e/bBgAAb1fDeYc0WDF5m2uOOT4QS0vFskEtGRq6TlDtFQ4zc2Z8XpuwKcbvJGNzV/zfuP4I7Ch1U3KuE/3Qf6Xzfb+ISeQMWGIdis89DIzTDD3/DVWiEAgZgDNaJunorJMotV1niV/ggng4En2KrXijYe8H4FHHBSp9UAgJK8j99V9rb0Jl+8aC9eGDUk4u5H88UT5fFTPiaQ35ed0uIUps9d7+qauJvGe762MNpwUBEuD0fbSGT2e2kd2UUaJUORbcHfY3sXwgT/eF36kyUjQkFC0c0fL3FuXEcVarFHL9GKKmu/AIQHKVYzXZEBrICBrh0= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 85a3a743-bacc-44bf-700d-08d6ff9a1a48 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2019 09:37:44.9215 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: anoobj@marvell.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR18MB3118 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-03_03:, , signatures=0 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" Hi Thomas, Please see inline. Thanks, Anoob > -----Original Message----- > From: Thomas Monjalon > Sent: Wednesday, July 3, 2019 2:21 PM > To: Anoob Joseph > Cc: Mattias R=F6nnblom ; Bruce Richardson > ; Jerin Jacob Kollanukkaran > ; dev@dpdk.org; Nikhil Rao ; > Erik Gabriel Carrillo ; Abhinandan Gujjar > ; Pablo de Lara > ; Narayana Prasad Raju Athreya > ; Lukas Bartosik ; Pavan > Nikhilesh Bhagavatula ; Hemant Agrawal > ; Nipun Gupta ; Harry > van Haaren ; Liang Ma > ; techboard@dpdk.org > Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper > library >=20 > 03/07/2019 03:35, Anoob Joseph: > > From: Mattias R=F6nnblom > > > On 2019-07-02 18:18, Anoob Joseph wrote: > > > >> For what exactly is being proposed, is there a short version of > > > >> the suggested > > > approach and the logic behind it? > > > >> I think eventdev should be simple to use and could be added to > > > >> any example like l2fwd. The idea of forking an example, where we > > > >> should be able to have an unified API, is a proof of failure. > > > > > > > > As Mattias had mentioned earlier, eventdev is complicated because > > > > of a > > > reason. It exposes lot of configuration which can be used to > > > dynamically load- balance real world traffic. With various adapters > > > like, Rx adapter, Tx adapter, crypto adapter etc getting > > > implemented, applications can better utilize capabilities of event > > > device. But all the existing example applications in DPDK is > > > designed around mbufs and polling of cores on various devices. If an > > > application has to fully leverage capabilities of an event device, > > > it has to setup all these adapters and devices. And, as Mattias had > > > mentioned, this involves lot of configuration. This configuration wou= ld be > repeated for every application which would need to run in eventmode. > Eventmode helper abstracts this. > > > > > > A question I asked myself when I had a look at the patch set is: > > > does eventmode really abstract processing pipeline configuration, or > > > is it merely making a bunch of assumptions and hard-coding a bunch of > configuration parameters. > > > > > > Merely reducing flexibility doesn't qualify as abstraction, I would s= ay. > > > > [Anoob] The idea is not to remove flexibility. > > All options of adapters would be exposed as command line args/ config > > file. For the first version, I didn't add it because it would > > exponentially increase the code. >=20 > You neither added it, nor explained it will come. > That's the main issue here: we are missing the big picture because you di= d > not write a clear explanation in the cover letter. [Anoob] Following is from the original cover letter. Usage: ./l2fwd-event -- -- -- --transfer-mode 1 The above command would invoke eventmode and with the default conf loaded, = traffic on one port would be delivered to all enabled cores. Planned features, 1. Eventmode helper library doesn't intialize ethdev. Since all applications already do this, eventmode helper would start from reconfiguring. 2. All features of eventdev and adapters can be exposed to the user using common CL arguments. The framework for achieving the same is already in place. It has to be extended to support more features. 3. Documentation is pending. Created new app based on discussions, http://patchwork.dpdk.org/cover/40884/ https://patches.dpdk.org/patch/40901/ Tested with nicvf eth PMD and event_octeontx event PMD on Marvell's CN83XX = platform. I thought this would be sufficient, but the above got truncated in some of = the emails. I hadn't realized that the mail thread lost this info. >=20 > > > > For an existing application to be moved to eventmode, all it > > > would take is couple of function calls and fine-tuned worker thread. > > > > > > If you want to use eventdev as a very complex implementation of > > > software RSS, sure. > > > > > > If you have a problem which solution requires a multi-stage > > > pipeline, going from a run-to-completion model to a scheduled > > > pipeline is going to have a big impact on your code base, and > > > eventdev configuration will be a relatively minor part of the work, i= n the > typical case, I would expect. > > > > [Anoob] Why do you say this approach cannot work in multi stage > > environment? You need to increase the number of event ports & queues > > as required (using command line args). Few ports & queues would be > > used by Rx adapter & Tx adapter. Rest will be available for the > > application to do the multi-stage pipeline. > > > > Also, for some applications, this complexity is not needed. > > Say, for l2fwd, none of this complexity is needed. > > When we attempt ipsec-secgw, multi-stage might come into picture. >=20 > Again, we need to get the big picture. >=20 > If you are trying to achieve a processing pipeline, why not using Packet > Framework (librte_pipeline)? [Anoob] Aim is not to introduce a processing pipeline. Instead, the usage o= f the event device for handling packets. All example applications receive a= nd send packets using eth Rx burst & Tx burst. In eventmode, application wo= uld do enqueue_burst & dequeue_burst from event device. When working with e= vents, application will be able to use eventdev for achieving atomic update= s (like sequence number in case of ipsec). > > > > Just to remind, this is the 3rd iteration of submitting patches. > > > > The first set of > > > patches were submitted by Sunil Kori from NXP and that involved > > > additions in l3fwd application. It involved addition of lot of code, > > > and Bruce wanted to make the additions common. Jerin suggested to add > these in event dev library. > > > > > > > > The second iteration involved additions in l2fwd and introduced > > > > eventmode in > > > eventdev library. Then it was up for discussions again and it was > > > decided that for l2fwd, a new application for eventmode would be > > > drafted, but for l3fwd & ipsec- secgw, the original application > > > would get additions. L2fwd-event will be used to finalize the event-m= ode > library before extending to other applications. > > > > > > > > Now this is the third iteration. > > > > > > What is your point? > > > > [Anoob] We had been doing back and forth regarding approaches. > > If applications like l2fwd, l3fwd, ipsec-secgw etc shouldn't deal with > > events, it could've been decided in the first submission itself. >=20 > You cannot blame us. > Yes we want this model to be demonstrated in examples. > And we try to understand how it can be efficient for the user, but we are > missing the big picture. > At every iteration we get parts of the explanations, so we give some > recommendations based on what we understand. >=20 [Anoob] I can understand the frustration. The patches were divided properly= and the header(rte_eventmode_helper.h) was sufficiently documented so that= information was not lost at any point. As I said earlier, some information= was lost, and hence the current predicament. =20 > > > >> About the helper, I see some command line processing and other > > > >> things > > > which have nothing to do in a library. > > > >> Actually I fail to understand the global idea of this helper. > > > >> There is no description of what this helper is, and even no name f= or it. > > > > > > > > All the eventmode configuration need to be user defined. So either > > > > every application would need the code duplicated (how the code for > > > > lcore-port-queue conf required for eth devs is repeated in every > > > > app) or be kept common. Again, that can be kept as a separate > > > > header and can be copied around. I don't see any issue, if you are = fine > with it. >=20 > User configuration may be defined differently in every applications. > If something is *really* common to all applications, why it is not in eve= ntdev > library from the beginning? >=20 [Anoob] May be I'm repeating the same thing. But here it goes... For ethdev, all applications have code to parse the port-queue-lcore config= . And every application has the same code to setup the ethdev with the ment= ioned conf. Eventdev with Rx adapter & Tx adapter is just like an eth devic= e with more configurable properties. So the same code for doing the configu= ration has to be added to every application. Sunil's first attempt was this= way and there were discussions about how much code would be duplicated whe= n attempted for another application. For ethdev config, is the code duplicated right now? Yes. Is that a problem? No. Because the number of lines is not that much. For eventdev config, will the number of lines increase? Yes.=20 =20 > > > OK, so in real-world applications, duplicating eventdev > > > configuration is not a major concern. You will have very few > > > applications, and if they have a similar structure, you can reuse you= r > proprietary framework. If they don't, no big deal. > > > Just an additional 1% of application code to maintain. > > > > > > For the DPDK example applications, the situation is very different. > > > Many trivial applications with a similar structure. I'm sure solving > > > the framework problem for this subset of applications is easier, but > > > I would expect such a library would have limited value outside the > > > realm of the example directory. Although it might make the DPDK > > > example code base more maintainable, my fear is that it'll just > > > confuse the reader of the example applications. Now they have to > > > understand a framework *and* an application, and not only the > > > example application. Add to this that the framework you just spent ti= me > understanding will also not provide - at least not in its current form - = a good > foundation for non-trivial applications. > > > > > > The DPDK APIs shouldn't be optimized for example applications. > > > > [Anoob] Initially the target would be only DPDK applications. > > As I had mentioned earlier, I'm dropping the idea of making this a > > library/common code. My proposal is to have all the code in > > l2fwd-event application itself. > > In that case, would you have any problem? >=20 > No I think that's fine to do whatever you want in this forked example. > But remind that you won't be allowed to fork one more example until thing= s > are settled down and approved by the technical board. [Anoob] Idea was never to fork any example. If we are in agreement with goi= ng with just l2fwd-event (and all the code in one directory), I can start w= orking on v2 patches with the agreed changes. Also, what is your suggestion on when we can take up a more complicated exa= mple (let's say ipsec-secgw)? When would you say things are settled down? =20 >=20 > > None of the DPDK APIs would be modified in this effort. > > > > When Bruce looked at the patches I had submitted to l2fwd, his opinion > > was, there is lot of code to just do initialization & configuration. > > But here you are saying, that code is very minimal compared to the > > applications. > > These are all perspectives and I would like to get a consensus. >=20 >=20