From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0044.outbound.protection.outlook.com [104.47.37.44]) by dpdk.org (Postfix) with ESMTP id B6E30106A for ; Sat, 26 Nov 2016 03:55:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jYLvejuvKKqLsSgwLWpHd976GdUatk57azTlup/b0rE=; b=KaEdUf/7rh9MmACX2RRtMGH5OaC9MMC2ksNAljcRZaJpJuu1BISuRQxTZFLzXSfWhuphsyT2NG3MQNLM1tTQ8RbEwmCgtETl2Kd+v0D7+XyaB35qZye9HyY6fHmYTbFrfh63k+hrb+RhNRh2JdWYYlHhGQdORJFn6hSBU8iaVIo= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.Jacob@cavium.com; Received: from svelivela-lt.caveonetworks.com (50.233.148.156) by CY1PR0701MB1725.namprd07.prod.outlook.com (10.163.21.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12; Sat, 26 Nov 2016 02:55:00 +0000 Date: Sat, 26 Nov 2016 08:24:55 +0530 From: Jerin Jacob To: Bruce Richardson CC: Thomas Monjalon , , , , Message-ID: <20161126025454.GA13886@svelivela-lt.caveonetworks.com> References: <1479447902-3700-1-git-send-email-jerin.jacob@caviumnetworks.com> <3691745.y1f1NvKTEv@xps13> <20161124015912.GA13508@svelivela-lt.caveonetworks.com> <1883454.103LptOkIX@xps13> <20161125002334.GA21048@svelivela-lt.caveonetworks.com> <20161125110053.GA149796@bricha3-MOBL3.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20161125110053.GA149796@bricha3-MOBL3.ger.corp.intel.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Originating-IP: [50.233.148.156] X-ClientProxiedBy: BN1PR08CA0049.namprd08.prod.outlook.com (10.242.217.177) To CY1PR0701MB1725.namprd07.prod.outlook.com (10.163.21.14) X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1725; 2:/c+jFUE4ornozS/cfCwo47r9bWgoHqJ2NrQrOwpbM3QGwB2EA4TNSCAN7wzN0+HNk4tU0TFNF8xlLcCIkmRQ8KjYqOzckdkwp1eSb5DGBrif72emdUado+TIwHGrgH5L3AQ88jFu8bNCu3u+9O+o34ajWpeQuNU3bVnI3QHTCkw=; 3:ErNxXdvwZMaOT6Eiops6U9LI6PsCxztJBT6ZAxbAstdsTke+A0KxNNjxLYz+YxWGToqMFqHlaPZYOH3eGnSD87IMtQD+rfC0K/ddfxyyLqxk3ELBfvsCfbUsefJ8rVS8dWJFxJmXth9WoJgNzsVPioGMi0cFabbEC73FzFpF4NA=; 25:rtWN1POmh7GVwQ3aTglXJnh06XM0oOMX1w7q9ekJaCZU+oIh2HfylXM2bZsMd5MO/UKRtG0Leo7/vd9mSGXY8PtSKGkqT3OCUk9JpwRBID5LXprueKdeOO2shxuLXuu/vayiGVSgpVNJUsCCFFoezYSxLbBsnhDk6mPLQ71XBoLaslUA1amKUu1F4a9n89PDDCLm7s+RxjHRNhB/sNBzI3vr7+osa9/NBMM61ON2QCFflJvSY3qDlPuMzP2rnLv7GG4nSIj6DaPE5eV9n1Wta88ARrXNhH/CHnOvhey9+dzVEGz1YJFMnVpAUK3YsFTyo8q24ShGWx6DgeO5Y5yNFz5TMVQXmLOqtMWhUTYF09JmFm+iJvR4Y91Bg6cdp9XilmJbKoGNDBmMKmbTcGpVB+dlfjh1pKCSftRf3eSYmlqzjv4jYH4EiHYoWt5lbaMFPJdXfFBFyvI2RYLfJPUwNQ== X-MS-Office365-Filtering-Correlation-Id: dcffe701-fcea-4ecb-b6e2-08d415a79da7 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0701MB1725; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1725; 31:XtYezzxypaE+vryROZWdVWrBJp3HTDXZ0cjCQuvcjW+1calfhO4PkVmVnMAm4GuIWYNRG2kVblIhoioi7CjYLiZpH4MvegkRx66eCp0mcMlcuYRH9AmBh9bGYn1G1wjUdCxkeuueRtjowyGsAodzN4/eRl1m+rHSf9YWz0SzyS9z+oG7CT6Rb8Y//hD4gzj+YtYYGAJjTyn5GOYhjtj0C7uD1KpKFTjOy8stPcNv93Nsj3iV2rM63TgQgFcmHztmAo2q9gpxnSiClTOA8fh42A==; 20:x1h23ItBwK/R4QW/N2iWK3FYATqTqPCOArD4Z16aZZvD5cidRg4iPkPyJ+FhXuXE3Uif+uLZlRM442KfoovZZ61hlqyQPJNF8kbyDkLbqJ1AuIB/kqXzPACEbVZLM/QvsQzbLAQ+J+hiXgr25gebGEjMugQFnGDfZts3OiJOFKUPW6bCxXTvpTfTfGVD7pak9GlCL3Fs59WGfZh1R6R3cg1p8d9l710XFJAjXHeLe+qQwYKfQhJ/deG1jqRx0o6UhIEY+ZviNLZ6U3cLFq/F/F3zdvoAfFpH1FMYH7wl3LmIE/IGcsioQxutR9y+OpcKLs+qT8HliUcv/Z4Ue5+ei8HYVz738CNrwVh1RNSQzmpsNv26fVftS3jRbEvbxYjiKP+kfj7KVvwKU1CswoRD8OvIkNAHjtdIjM322/HXIsuYjUna/8/11drLU9coh84FOjWSzg8bkrowGHYoZp0Dp8dhK+XnN0D/kABVYWCz/m7ITWpWw+lP5LEbVh+8mgOR+RVQfK92XB1e+I5hqZe8Q2e5R7YUBM66QkOf+tyxDuYL0FttC4qR/xRnKPl6BVmvB5fzr0orSXR8c71IrNGGP3VAAcCkoReDk7uQugr81R8= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6045199)(6060326)(6040361)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(6061324)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(20161123558021); SRVR:CY1PR0701MB1725; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1725; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1725; 4:wNC7Rzm+PHLj0tL993OveDdEi4yh9oQ6cNc7i+PSDjNqkKuj7k5Q7NdOakAyErnjCYt9dZUADSxDiVaIJs/c2dZEFGkUuz7USEDavEXFONfa7FJdUtXr/UsBRswWv14VZNQALjfIxO4jqj3T/54KJXc/2Ykre9K36Oye5Jkz3kIFMfW0I/Fmxzo0+XtoGO6y3Y6ER1ionjzuDio2xR8gQRn0wLnwLad5wscDhtS8sB+Xmw8tWEk+91fOIwuD5rD/S6toXkgdybc8fhnytfJTZk8Gj8E3W+wW72flHGh82ls5ePnLlqHktdjfaqzgXjK7jo/R2WwA6l2Au733uudq3PR2mZzoKKeswtq/WCamr0AZcoH9xeKv7eZIja7MxXQUJJOpGSbe9M6SncZGBIisbcjbO2M5EvWGQt3LAVLN3oDoNLrUMwCNzvpGbYTApACMFSHXb32o/2okoDHDMhz2CzSOf4fg8ngYupkRxoHXL8WQwm/zOo85L2QvLTuA/wiGR+ugxMjYLZOyKqZejnOhuXKv9z1dUHVl9NPr+hRjFBF1JX0/NVyKe7vVRBzq8pvz9wVX9Nebsl+AqscbbHDHzP//PLX181dNJCAw8yb4Nb00DJel4A4pCBrdVbeFbp06iI2DZqrsLCc2Tn6ADcPT1A== X-Forefront-PRVS: 0138CD935C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(7916002)(24454002)(189002)(199003)(377424004)(3846002)(305945005)(7736002)(7846002)(39410400001)(46406003)(105586002)(81156014)(39380400001)(5660300001)(110136003)(6666003)(92566002)(50986999)(97756001)(2950100002)(101416001)(76176999)(93886004)(6916009)(9686002)(106356001)(42882006)(68736007)(54356999)(4001150100001)(69596002)(8676002)(97736004)(42186005)(47776003)(189998001)(4001350100001)(6116002)(23726003)(33656002)(39400400001)(50466002)(4326007)(83506001)(8666005)(38730400001)(1076002)(2906002)(66066001)(53416004)(733004)(81166006)(229853002)(39450400002)(18370500001)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0701MB1725; H:svelivela-lt.caveonetworks.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0701MB1725; 23:UpwafhfecDZs7EHQtETux6SC2rRzQ2OLMAJMYzu?= =?us-ascii?Q?bBoBU615sRUEiPScbmTM4s8TryD7JjtevdB3j5gpipC2pY+z3HguLIXCijj9?= =?us-ascii?Q?VL9TW1DECO8og3CSu9eRYgGPGJyA1hCrnfAjR3HbiwJj8BHrJic/rLFNJ0Ih?= =?us-ascii?Q?IzwI5FuwMgZWd/H3IYHXJoRARSgf2cUL2wqPsB/IKodni+GrrcVz2LqrtrLm?= =?us-ascii?Q?roVh8J4Qu9tyNfjwTySkcF1u6DMrv2iXep8/siWAswl+7DuZ4G4LjE4GRw4S?= =?us-ascii?Q?WGoFkEoa8r9P8SjLOH2qgXHy7lgCmICItm0CjOtdizk+awOAcBFlTKERnC3N?= =?us-ascii?Q?UYn/xZilFrllwIds0WoZlFVJW4+jp51c78lnzsAZ7fmVVDPHn5bhQUSe9BYX?= =?us-ascii?Q?0gFp2vxqjYG0rGYr170s8niPbfNzeLlETbJ7mgiu+Rb29RyaeN8CCbIQ8HnL?= =?us-ascii?Q?8Lwz/U6kGU0eaww+7lZMJ546CDygYz51zJ1s6wLhzvpN0v39vBA4jEhknJtT?= =?us-ascii?Q?8BKELS4xljxTgBmJfuMZHGKfTO7e2rXDA/DTOsk7eAjPg1KWjOORPrDJfXap?= =?us-ascii?Q?ScbEB252EAvvEsxZA24R+fWCn5Ezn/6o8j6lOc9jlQhyM9VpZt1509T9LeAA?= =?us-ascii?Q?FzJXIE4S4HEYNDBVxAS+TWzlviHgr81TYvaaAW5tV76Y+d8FfrqRk+KqpETa?= =?us-ascii?Q?XdkpjPx+xZSm2H0i+SVqx7MiLaHwJdz1wpI4XuF5nc3v5AsnxRVis9NidbTs?= =?us-ascii?Q?Kd9a0sTMEdLsjdMESRuurw9yOkI2GLC3+T36wPED+JwfgXgDcnZzOOO5znTU?= =?us-ascii?Q?51ygsyxk97R/hbEIish7RXd34/TjuGnvJ4QxRQ0MlH73lsegzwYMdArdJRAG?= =?us-ascii?Q?GnZwuAS3iATQQwduZSMJZqNynxy3H5vxlKw3NCx455duFlyWHWkJq18cnmBT?= =?us-ascii?Q?Y/Sji2IXvz0HRk8aRywqqowf5Um5p6UA+qXk4Im57iuJpV0j5dmDcF3q7spB?= =?us-ascii?Q?8ezb4aYDoXUYQgXPRZeUMAFBl7Iz6mzbchuixP868YDbmWvZxYMwfQMnAF0g?= =?us-ascii?Q?WP3MxUHyyU2cCUQ2l7iRf2uzsNsiE2crL40xtwRsrBe1YVJjmbsrgwTj5N+X?= =?us-ascii?Q?KG4pDSM5k2KU/tDwswrDcXVqm0zIz5kzBy45xPrcc3u1DdgbGhaPouNm1JoK?= =?us-ascii?Q?VGDyoXcI5hd3O/n1bGd+SltzN4CUoNJdFfvqyk0pR521Wy3tfGFvXulctYy6?= =?us-ascii?Q?WuncuXRvYhz+oYJnGHOjAORHTOEVdaIAQ/uqF02dQ9SVQciEUyE7ghxS3GkV?= =?us-ascii?Q?KAScMCSU7dHNg4SACSlCOkN4KQiuuagJ71/0zStKwGa8chdcbbcL+hykUyUh?= =?us-ascii?Q?PjLsuLMJLlJADUNsBWCO6M2BefiOZQkVK0PEZkJkJJdrwhxK111vmPPEUiGP?= =?us-ascii?Q?EJsuL1Ze/usXw9J9mYBaBSdaglsEr4Fpcx8x3CQx5e+FchJkbfKwT?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1725; 6:W1H+eEAluwA8e49v0jDUzAa6f9g6tA03Z8z8YBDC5Z7OC2trB5l7/be0N+vI666ooTP+qrmvYLIopbBGXqD17jl3YwH+akCGVz1dnrvoHpmkWqA8vJQLSKYfINFRQCBK749I068LD2t9OxPdqt29SqdE9tL+dw9MdRGWQ/fMTz/c98uIsS34to6KtpZ2jojz5RrCU3+aTz4wK+3T/FDtae7SI5AM1/HDw+TtauBzB1ikZBx/oBl1Ix3jswxdBK+14DQW3M5zM0uSkYH3sr52CwieiqJTFmKEuqhnGp5hXmrZBwlR1Zj7f24ZLx1avBZgBEKRouqtrEY1iFX98YGCGQtFu59FrmTBOOeV3Xo7jaU=; 5:2/drukOUzc9f3xjU+LHUlkuQZZz3CaaGEM0MPiOCU9iQQ6waIAVG9IbrTP3TUa95Sn9tROAjtAT2DQJS7K4Go0JyCxJmoiGf/3eSYqLqEXtCpKgLcwSletvuO2T54JhhXrIG+9scA4CjIE+yUNhXLhEPI0J8GdmN+79WZX+Wh7c=; 24:HeupsZqN3c0fzu4FNDiMCwv6O1p/w//0JrS4ycgJzpsVpnNAkSFfvkndNQQj8o8K7h9jXpN5c/4kQrxNzq2wjBteIMRnze1WBgmo8e2NphY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1725; 7:D1Y/m6V4OgXoxf+Si8s9ghpwHnr3ie8W9xcQ4Ggk7uFFkpqeIdBemym/yaM/b+BdSFL9kNJ6UvatufMnt8dAB2IsszevHDI7mhJquo0QGM5vlMwOWGCO0LHtc4A54Xns3omLQHLOYLxSO37GtFwd1mwfTWwyzOIjCZUC0o0ScIF9LymRSIvsd/Fbnw0IT7e2z+9NC2eRUtBwxXpPHTNcIr8isd1+oa0jiXZEJr0edMPkeS2LqZg8/vjQ0g//bgPL+spl0nwasg8L2GdNUlapJuXwGXi+cZ+ZJzPgoyrRiHfO3esthJA+3Kd2qCjM4oRSjwkWFVKk97ZwMrk2ryXjVNgB++FGrgaQnoSLs+suhXU= X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Nov 2016 02:55:00.4505 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1725 Subject: Re: [dpdk-dev] [PATCH 1/4] eventdev: introduce event driven programming model X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 02:55:06 -0000 On Fri, Nov 25, 2016 at 11:00:53AM +0000, Bruce Richardson wrote: > On Fri, Nov 25, 2016 at 05:53:34AM +0530, Jerin Jacob wrote: > > On Thu, Nov 24, 2016 at 04:35:56PM +0100, Thomas Monjalon wrote: > > > 2016-11-24 07:29, Jerin Jacob: > > > > On Wed, Nov 23, 2016 at 07:39:09PM +0100, Thomas Monjalon wrote: > > > > > 2016-11-18 11:14, Jerin Jacob: > > > > > > +Eventdev API - EXPERIMENTAL > > > > > > +M: Jerin Jacob > > > > > > +F: lib/librte_eventdev/ > > > > > > > > > I don't think there is any portability issue here, I can explain. > > > > The application level, we have two more use case to deal with non burst > > variant > > > > - latency critical work > > - on dequeue, if application wants to deal with only one flow(i.e to > > avoid processing two different application flows to avoid cache trashing) > > > > Selection of the burst variants will be based on > > rte_event_dev_info_get() and rte_event_dev_configure()(see, max_event_port_dequeue_depth, > > max_event_port_enqueue_depth, nb_event_port_dequeue_depth, nb_event_port_enqueue_depth ) > > So I don't think their is portability issue here and I don't want to waste my > > CPU cycles on the for loop if application known to be working with non > > bursts variant like below > > > > If the application is known to be working on non-burst varients, then > they always request a burst-size of 1, and skip the loop completely. > There is no extra performance hit in that case in either the app or the > driver (since the non-burst driver always returns 1, irrespective of the > number requested). Hmm. I am afraid, There is. On the app side, the const "1" can not be optimized by the compiler as on downside it is function pointer based driver interface On the driver side, the implementation would be for loop based instead of plain access. (compiler never can see the const "1" in driver interface) We are planning to implement burst mode as kind of emulation mode and have a different scheme for burst and nonburst. The similar approach we have taken in introducing rte_event_schedule() and split the responsibility so that SW driver can work without additional performance overhead and neat driver interface. If you are concerned about the usability part and regression on the SW driver, then it's not the case, application will use nonburst variant only if dequeue_depth == 1 and/or explicit case where latency matters. On the portability side, we support both case and application if written based on dequeue_depth it will perform well in both implementations.IMO, There is no another shortcut for performance optimized application running on different set of model.I think it is not an issue as, in event model as each cores identical and main loop can be changed based on dequeue_depth if needs performance(anyway mainloop will be function pointer based). > > > nb_events = rte_event_dequeue_burst(); > > for(i=0; i < nb_events; i++){ > > process ev[i] > > } > > > > And mostly importantly the NPU can get almost same throughput > > without burst variant so why not? > > > > > > > > > > > +/** > > > > > > + * Converts nanoseconds to *wait* value for rte_event_dequeue() > > > > > > + * > > > > > > + * If the device is configured with RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT flag then > > > > > > + * application can use this function to convert wait value in nanoseconds to > > > > > > + * implementations specific wait value supplied in rte_event_dequeue() > > > > > > > > > > Why is it implementation-specific? > > > > > Why this conversion is not internal in the driver? > > > > > > > > This is for performance optimization, otherwise in drivers > > > > need to convert ns to ticks in "fast path" > > > > > > So why not defining the unit of this timeout as CPU cycles like the ones > > > returned by rte_get_timer_cycles()? > > > > Because HW co-processor can run in different clock domain. Need not be at > > CPU frequency. > > > While I've no huge objection to this API, since it will not be > implemented by our SW implementation, I'm just curious as to how much > having this will save. How complicated is the arithmetic that needs to > be done, and how many cycles on your platform is that going to take? one load, division and/or multiplication of (floating) numbers. I could be 6isl cycles or more, but it matters when burst size is less(worst case 1). I think the software implementation could use rte_get_timer_cycles() here if required.I think there is no harm in moving some-work in slow-path if it can be, like this case.