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 3A78AA0487 for ; Tue, 2 Jul 2019 18:18:09 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CFF2B1B9B1; Tue, 2 Jul 2019 18:18:07 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id 0C4371B9AE; Tue, 2 Jul 2019 18:18:05 +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 x62GHj7q010780; Tue, 2 Jul 2019 09:18:05 -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=eEGXElI+5FIBuXPLtH9kdlSFdAg0Z2sPSWXOGTU1aAA=; b=wKJRxnp2yw0uL9+l9tzf2a8mn/QUCTjcToU0yFSz1xIdvNrviLXU7EMFmKs2eVEstD1P fse3lDw017q84ERxqwHa8U4hO9BeBx72nvNhx9Q8X3DyzsWN0gXDtGr/1aGEnspt/Xzg V4m6fuf/mgYHt+doG16srPX6mp3jML5jzuahRm6k1OrmYf7bX9qd4re0hpjB/paTL3FJ ocH0CNIrju78SBhYoLoC8I5eqhypHztdOy/n0RRIqNGqO/n7TXAnru9v+hfy7XHbFjmG 1hu5HBqZzTguV/M8T7AeVnoM6TNTy1jvRV5SV6icUCIHsIAPaBkkxq81xnq0xkRusTn8 ng== Received: from sc-exch02.marvell.com ([199.233.58.182]) by mx0b-0016f401.pphosted.com with ESMTP id 2tg5731k30-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 02 Jul 2019 09:18:05 -0700 Received: from SC-EXCH04.marvell.com (10.93.176.84) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 2 Jul 2019 09:18:03 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (104.47.38.52) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Tue, 2 Jul 2019 09:18:03 -0700 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=eEGXElI+5FIBuXPLtH9kdlSFdAg0Z2sPSWXOGTU1aAA=; b=SODDP295MUg/IYwed6fb+Lr/gBkATWiLvnMSozbLaPXagSpbi3unGO3WUlfW+zJ8dW3C/IVQMsudWD3htmBMnr/s6y4wgEhDQe0ZkGQ8HLgRLMNBPsTKT6NyyYWB2Cs/vNAzW5S6StFsahjngU4imAyrDKIIzMy2T1GakMBId+E= Received: from MN2PR18MB2877.namprd18.prod.outlook.com (20.179.20.218) by MN2PR18MB2829.namprd18.prod.outlook.com (20.179.20.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Tue, 2 Jul 2019 16:18:01 +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; Tue, 2 Jul 2019 16:18:01 +0000 From: Anoob Joseph To: Thomas Monjalon , Bruce Richardson CC: Jerin Jacob Kollanukkaran , "dev@dpdk.org" , =?iso-8859-1?Q?Mattias_R=F6nnblom?= , 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+UIrk446laa3YooAgAAIhgCAAAcs8A== Date: Tue, 2 Jul 2019 16:18:01 +0000 Message-ID: References: <3848960.f2llPjXIeu@xps> In-Reply-To: <3848960.f2llPjXIeu@xps> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [117.98.153.232] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9e27a7ac-5db2-43f5-7125-08d6ff08dab4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR18MB2829; x-ms-traffictypediagnostic: MN2PR18MB2829: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 008663486A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(4636009)(366004)(136003)(396003)(376002)(346002)(39860400002)(13464003)(189003)(199004)(66574012)(229853002)(5660300002)(110136005)(7416002)(52536014)(4326008)(71190400001)(71200400001)(9686003)(316002)(6436002)(99286004)(53936002)(66446008)(33656002)(478600001)(561944003)(14454004)(54906003)(55016002)(2906002)(6116002)(76116006)(64756008)(66946007)(66556008)(66476007)(73956011)(66066001)(256004)(25786009)(6246003)(53546011)(476003)(7696005)(3846002)(86362001)(68736007)(14444005)(486006)(11346002)(186003)(102836004)(26005)(76176011)(6506007)(305945005)(446003)(7736002)(8936002)(8676002)(74316002)(81166006)(81156014)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR18MB2829; 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: YDlCVQD46TFK8BADbx24n1jqBF2Bng1J1XD++2/UiQ8bQFUuT1mAu2ZZ9s2ilGwqxshCDuVGb326zSK52MdGi3mU3RynEDfn1Whc1alCLCl18rSr2RNyXXgk0FxynOHMQuKndFbd/RmqKOkG7iuwa9Xpim35jTQr0Il1GPHxnZ1wCMA/Myo6zSsNz2JEXieEYCBnK16cBOXByQoo/pKFwH450Pre69srlyHkMe8T12aeieh/slDm4671nXp+sbaJe2kw0iFLFTpwQAr3n2G2qmpRnMFpioJYdT2WOsvdkpiW4i01/iDoLOP30Mr6XLKAsT3P2zRKLfo9poyyY9GmNUNYco7PsPRgqcngTOSzDS7MdATUg7U/VTUqVWEWJxa4UwV9ML8JGYVlIcB6r4OPnvjpai6ct0QDX94qLb++fyw= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9e27a7ac-5db2-43f5-7125-08d6ff08dab4 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jul 2019 16:18:01.1454 (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: MN2PR18MB2829 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-02_08:, , 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, Bruce, > For what exactly is being proposed, is there a short version of the sugge= sted approach and the logic behind it? > I think eventdev should be simple to use and could be added to any exampl= e 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 reas= on. It exposes lot of configuration which can be used to dynamically load-b= alance real world traffic. With various adapters like, Rx adapter, Tx adapt= er, 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 ha= s to setup all these adapters and devices. And, as Mattias had mentioned, t= his involves lot of configuration. This configuration would be repeated for= every application which would need to run in eventmode. Eventmode helper a= bstracts this. For an existing application to be moved to eventmode, all it= would take is couple of function calls and fine-tuned worker thread. 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 addi= tions 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 i= n 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-ev= ent will be used to finalize the event-mode library before extending to oth= er applications. Now this is the third iteration. > About the helper, I see some command line processing and other things whi= ch 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 for it. All the eventmode configuration need to be user defined. So either every ap= plication 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. Ag= ain, 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. The idea of this helper is to allow applications to run in "eventmode". Hen= ce the name, eventmode_helper.=20 > About the copy of the example itself, you are copying it as first patch o= f this > series and then do improvements only to the copy, leaving the original be= hind. My original proposal (additions to l2fwd) was fixing quite a lot of things = in the original app. Bruce was hesitant about the changes and suggested imp= rovements only in the new app. I can add improvements in l2fwd also, if tha= t's what you suggest. IMO, keeping both apps similar would be better for ma= intenance of l2fwd-event also. So, please suggest the approach. > So my suggestion is to do your PoC in a standalone example, improving the > original example at the same time, and try to improve the eventdev librar= y if > possible. Then we should not propagate this design to more examples until= we > have a proof that it is a progress. That is the proposal right now. L2fwd-event would be the standalone example= . If code duplication is not a concern, I'll move the eventmode helper file= s to l2fwd-event directory. Then we can continue working on adding the feat= ures there before moving onto other examples. Please conclude deciding the approach to be taken. Thanks, Anoob > -----Original Message----- > From: Thomas Monjalon > Sent: Tuesday, July 2, 2019 8:27 PM > To: Anoob Joseph > Cc: Jerin Jacob Kollanukkaran ; dev@dpdk.org; Mattias > R=F6nnblom ; Nikhil Rao > ; Erik Gabriel Carrillo = ; > Abhinandan Gujjar ; Bruce Richardson > ; 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 > 02/07/2019 16:26, Jerin Jacob Kollanukkaran: > > From: Anoob Joseph > > > Hi Thomas, Jerin, > > > > > > Is there any consensus on how we should proceed? Can this be taken > > > up by techboard? >=20 > OK, let me give my detailed opinion. > Summary: I don't like this situation at all. >=20 > I think eventdev should be simple to use and could be added to any exampl= e like > l2fwd. The idea of forking an example, where we should be able to have an > unified API, is a proof of failure. >=20 > About the copy of the example itself, you are copying it as first patch o= f this > series and then do improvements only to the copy, leaving the original be= hind. >=20 > About the helper, I see some command line processing and other things whi= ch > 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 for it. >=20 > > For me it make sense to move these helper functions to examples/.. > > and make it as standalone(not as library) Suggested directory(In the > > order of my preference). No strong preference on the directory name > > though > > 1) examples/helper or > > 2) examples/common or > > 3) examples/utils >=20 > If we are not able to give it a better name than "helper" or "utils", it = is like > moving it in a trash folder. >=20 > And last but not least, there is not a lot of reaction to this series. >=20 > So my suggestion is to do your PoC in a standalone example, improving the > original example at the same time, and try to improve the eventdev librar= y if > possible. Then we should not propagate this design to more examples until= we > have a proof that it is a progress. >=20