From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690059.outbound.protection.outlook.com [40.107.69.59]) by dpdk.org (Postfix) with ESMTP id 491902C5 for ; Thu, 9 Aug 2018 16:18:32 +0200 (CEST) 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:X-MS-Exchange-SenderADCheck; bh=16iEoM/7N2767SAfxoymsuYW/dUAzq1mp8SN61b5Qu0=; b=Df+bfMIgbCO6INlt0wZv3sXHL/AgQ4pn2QSVYpfh1TNynRj/sLomaidnA2oyzRjLVzY7mWibiEFgO206CyHW8NRM1L6ctFN4IKPE+XDxpKIPFoYpJ+D2o5I+QNLC1RqRGcqGKgreUkUa2IqSfWQYaSiaQ+qQD+V9jWhTnkwcNoY= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; Received: from jerin (106.201.112.75) by BL0PR07MB4995.namprd07.prod.outlook.com (2603:10b6:208:49::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.15; Thu, 9 Aug 2018 14:18:28 +0000 Date: Thu, 9 Aug 2018 19:48:17 +0530 From: Jerin Jacob To: "Van Haaren, Harry" Cc: "Elo, Matias (Nokia - FI/Espoo)" , "dev@dpdk.org" Message-ID: <20180809141814.GA15603@jerin> References: <20180730092921.GA22242@jerin> <20180730103638.GA26701@jerin> <75889C0D-2790-4EB8-B202-1311D764CCF2@nokia.com> <20180730142614.GA11265@jerin> <6D43DE84-583D-42E5-B298-0E7BDA0C17FB@nokia.com> <20180731083107.GA23233@jerin> <4C54AAAE-A872-47E1-B815-AF68965F9F3E@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Originating-IP: [106.201.112.75] X-ClientProxiedBy: SG2PR02CA0043.apcprd02.prod.outlook.com (2603:1096:3:18::31) To BL0PR07MB4995.namprd07.prod.outlook.com (2603:10b6:208:49::24) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 978afa20-0a8a-44bb-b907-08d5fe02fb09 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BL0PR07MB4995; X-Microsoft-Exchange-Diagnostics: 1; BL0PR07MB4995; 3:r0zO8i/EehQePpq1QTgZIAv3j1DkFsrfHoZBsF4TDxDJUjLcYTU0XeOxq1gfaUkobyXB68VldYZoACHgEy8Lp5XxSGq7knuU1Ev8haF+lq42+zplZ2ybEIfG/xF8/gKjmQrq89kIRQpk8fbszR7qduVsA6YQb7oqsHMrTkwlEwsyS6Y0fQ2Epjp5YuaLZaQi24YkTxUTsHaXqNd+IrwYAQvmmMwSezZs7WBxe8RquNg7cp3779O96zsou4gdkcu/; 25:iZIL19jmAWRE3rC0+RpGO6inuUoJMqBi073E7QqLlEo1ZYovpQrFLS9UFvzskiEl7kbDyC0SjdI6rxlijQE4Y8OeN7UjMQODumiDNk1zNDRBYd/Jwj9QFvURGB2vJAXhkSS7i45aHLmT+YQDBkaYcd37iR54w4sEwqn0gnjd6e4psBAX4rL75DVfKGahaxrF5fhzkEd/Dyey/MmLAQJu30CmDVJdqEsnHEcLZaNbfymCjoSiyj2BilSOYfZrmcgv4VLIOzU8uLmQtn2haujDFDGACMdY9dKXAlLJQc+eFBYWM9qe5ypa7SvDOYCeR38p83hch0MW3TBscdvIzI7p5g==; 31:ZgU39ae+If/rutRXZTLZSkhzoE5H6PjWXF+PBN/Bl1sUkehpHR7PsERQTJrgakopY7dgxtiSE6oAyA7QaINFUT6U2QbHzlxAKKGEmeKBb0rXBjJu86Kb3g4l6tnUVVdMp/a4yY3jdX73eEcnMmY4pZFmdTPdX2mosWZjE4ZmlMdIAa0K1Io5l537uaemENEO3MkS6DLsPfX3daVCya4hPzLtn7A0ntygv43CUYt/iE4= X-MS-TrafficTypeDiagnostic: BL0PR07MB4995: X-Microsoft-Exchange-Diagnostics: 1; BL0PR07MB4995; 20:0qaExWZuY7Nxl5TLR6WRJR/xTnUPIIV+m4nBmEYFMDA3jjh9nVjO7GnZL19/1J+5ICguEjiFq1y08LqjCSL5APycc+SVu+PvrN6rb98bjdxc1jVjV820IRLL6ac8vR/n6jG38kKZ+7ldgPGfcTfmW9MaIEv3Us0sHnCCbHyqDMavtIme4jWKxObwtM0tAYwfXM36AqY6OHd4PbZyJHw0ULTGRAOUCqByUL/4fXLbwnMIZKZg5PV7NFKFEY12muTroDzI4uF5Kr+ISZCuThNF27lBz0uFczzepB/CrPhUsKmpD9NKRLxuT+nD0+tfoYUth7MVnpZLv+agU8YkYCYNMX9zjm3Rgkstb1ZmKES6agEHtlHlQPaRp4qMeXik/hmCc2tlob3GxT3Rn6cfSKVVd5G+MobPmIwD75NfJUNL1aAKAhPC/KKLpU847jfLZI1O3QSpA+Enh7ww+bPDf9oZECZdXn12KpElh8IR1pzrAKuvqVn9gGefhPHw/KMxh187s5TZ34IqU0hZgTjwTT6WVXPRCvDJYn+hEC0g56h9men23PfBQgYjJSUat0bRpXF8W2Ut2+Ww0c7Rem51XuoQ4oZUfRV3DI5SrTZ5kiF1RIc= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(82608151540597)(109105607167333)(195916259791689)(228905959029699); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231311)(944501410)(52105095)(93006095)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:BL0PR07MB4995; BCL:0; PCL:0; RULEID:; SRVR:BL0PR07MB4995; X-Microsoft-Exchange-Diagnostics: 1; BL0PR07MB4995; 4:F0bl9ESmLFhF93wDqnYbWSgZptTWjJMaL8ens1G/qTte9DYdr1ozsC81If2xbIISrbLaTB7x0PG+vZIzcsBlajm+USmc63DtedczjUrWRciTV4MApblGPRMFqud2gvP6y+bEoC0E6QN/Urf5sv1h948DzfQVpBZM8+FjFEZYY/wXS77X79VGTITlJs7gi1rroC2KrAhqAb2CqOtgNgW3pVZP64tSf8+MqmzgDDAF8J4X130zuNfoN768XhQgceEVX94c3ekDrGJ/jQvElSnAqNEPvhsjN7pAa/rjC9tJdzRYSGY1iETgTIyID1TO5SrgY2jzhbmOwI/Sr0zMBhniKpH2upIqQvwpm0R17vpjijaIfimeNE1WXTWdxGGC2PGpvXmusDR+2QAQDE8hMmrdeverU5x0w921r8iqT32bAi4= X-Forefront-PRVS: 0759F7A50A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(39850400004)(366004)(136003)(396003)(346002)(376002)(57704003)(52314003)(13464003)(199004)(189003)(72206003)(476003)(97736004)(66066001)(386003)(68736007)(486006)(7736002)(58126008)(54906003)(53546011)(55236004)(26005)(14444005)(478600001)(55016002)(44832011)(93886005)(4326008)(33716001)(9686003)(6246003)(53936002)(229853002)(956004)(25786009)(47776003)(52116002)(42882007)(106356001)(105586002)(50466002)(81156014)(81166006)(23726003)(1076002)(305945005)(11346002)(446003)(33656002)(316002)(16526019)(186003)(3846002)(5009440100003)(6116002)(8936002)(16586007)(33896004)(5660300001)(8676002)(76176011)(6496006)(2906002)(6916009)(6666003)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR07MB4995; H:jerin; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL0PR07MB4995; 23:LF6yuG/YotI1ZiJNYnpxsem1m76fhf9A5XapdKZKU?= =?us-ascii?Q?X9Bg2ILqwYOteUo8q5zW94aJgnxKkutewf+SzQQhzvh+fdSDngFqzBjLPk5j?= =?us-ascii?Q?m2GPwMTAe5KtCke+tqxi986Rc7AczzGaTLDwcsODpqgdgkCJA+UILWGzqVI4?= =?us-ascii?Q?y10oKHmi1bSsP1syLXxrZpbo6B+Y8bzHkNdfHIKcFb5uCqiS97ajGAptbenB?= =?us-ascii?Q?4/ac4tCA6umxBYM8RuCxUjgIrfkuZgtqGda0lNdItoIuPsN5GnKLOvWeiIvB?= =?us-ascii?Q?EOuo5OrxqZm6sl7dksIyM0VxwYZLg6EspK+VaZWjKXFvtyrDKmAzWOtiEh1K?= =?us-ascii?Q?9yd5znu3OY39rc5+C9wGBmjZuGQgV00IBGIjYXmRdYHY59JbXcia5Iw+/gQQ?= =?us-ascii?Q?XQa/Lphxbw6YyJkj3qNk8ADxf9CloCo9MtMtfuQdmHRI/UrtIoKwArN8ODi2?= =?us-ascii?Q?QxfGn0OikhtlxrJv7woxj+Fm7SiNUeFdAW8VXUr/4C/RZ0Qu2T7V7gh1VzhV?= =?us-ascii?Q?CyZwiBNyLHKY6Q8oaF5G7id78KyhAVHWBAlw7+39S8t2UDIl32OZtwKNtKcI?= =?us-ascii?Q?drb4OYpMv1hF9IDdDYq4SaJ9/aBK2xpQHGIV0tED0ei2dFnfy9DW2qEH8zbz?= =?us-ascii?Q?Dwxj/n35QPNCdebqnRzgOrKyxs/vg6tGw6swDAuUzq/UJ/0t72zdH+HcrIe5?= =?us-ascii?Q?HnGmGRxrjctV2NZpUzKKbqs9FNeLvXqNd9JMglHFYjKQYE29Wn7HI/BEutlr?= =?us-ascii?Q?Sndil1lvqIDhPGGtBJ/DoUyw/VhjCMbg9yIUOYqP464C1ZkKlFGtaudXBeCb?= =?us-ascii?Q?fF1L+29oYBxyZPhdAU2+2u+eV0iEgOI/iXGkp8KfPLB2CmSRaq8jeqk7L0gG?= =?us-ascii?Q?Qyzip0Vm4swsYzMZlsAa3V3PlPCv2g//P31WfP56VrgUu1qIBFig1F4J4b1K?= =?us-ascii?Q?mDbMNCg+GGNaSNGdP1cj7lJiTPwecJ0M2UGTj9m70wQc4oFe6cqM6ifO6+2/?= =?us-ascii?Q?bL82bMJkc+T0xyafYCAIXEG8NrGkeP/hkHtCAc48JhKy855+55ORJ5NarKcc?= =?us-ascii?Q?AvDviL6xrKSOjRaEoUf0KfuX6mk80mlW1BMe/L8wIHaICKQ4GNb+Vgim6uzR?= =?us-ascii?Q?UyZ3QJ4EY8H8V7Dufy/EJwjQCiH7o60p3rtGi0Iyk8y/vqHR0fb/leMSekon?= =?us-ascii?Q?Z1bYDqY9zt6/ncR8SuX7jN6sm4gADvOWIn+dn6aXgUf422aPNOelshxv3K/Q?= =?us-ascii?Q?knRzTdO3tSdq8ie/A9gXS30iF2w98gR2BOyJ0+TuBv9iMOWQqjdIS6uxMjmz?= =?us-ascii?Q?dxFjlx6QhhMJDzB7el2ggnz9MyMVBpQNyWiCcMHEBZjrlvVAV+lFFuM9HqnO?= =?us-ascii?Q?Z2clNjW6rjakqfssDXndODTtibrn32S6/3otW1OjlywXIJyGTBVbkK+hCJEu?= =?us-ascii?Q?8TqPfNI5SymN7TNQ3ArBj09acRWLkHlLbo6QaCYTNaWJsJHJKl2apprrqltE?= =?us-ascii?Q?WEntSgbEZG+Q7QW+8DK1zOHcqqZoEPw9nA=3D?= X-Microsoft-Antispam-Message-Info: aIwA/vxEDU7Z2wwpueiZB40MMob3Cp6UxkddR10l3lhhrfw/eKjb43DXx7msGspxq0zp3uMJBISbBTdiIjFlxaGxiyl7a6qSftAmr9rI/YfVzQWm2MFF1NvZEmuUlUTHK2AiVDeR+caQIyONFGxvvTEXjIahi+laM+plgPQ+oyZgeO6bK3wbIo0C/BYhZFRuAqGva5dwkrlWVqt+w5TpmfgttvXTeYVGpsBH2k4gi0VStyN6zNkxA6mwSfEejx3hfTgkimXq9csU8fZwJKr7zXJEaG6q6mBy89cj2aUIti/j9Oq0x4YtV8yIIyCPkSwa/0tGqhYzJSvUDKbqxtHv1sWdVCEgOO1Kxspex26Gzhg= X-Microsoft-Exchange-Diagnostics: 1; BL0PR07MB4995; 6:C8rBqkpEBQrZWdGSpBTj87GiwDOq/tOG2Vq5GR2fnnS5VhMVj4Iwsd9BJV9hPevE4oXsi9Vs67+jk3idbVp3sYYhyHKT2hY/FraMuLd33sOsYeJJ5zhKqGNSqb2jVQ0IUoxBHpMpRVj398dKZnChbQLQedbZMQKVyYs0A54tTgUbOSjq5a+jU16j3On44JDZRvt5mJja5bgB5tlzfVL3zR+fjkd96yukisnwNG3tndyWqSRs+Rrg+wsYNfb2olFwOYfDmqI6vV+MxbhBruirEh3BOYnI0z5Qnl9eCeWcx+KcjH8ijtB8IWYN2V+MCj4IKLvDF4hFx2uoR7+vKowehaJG04fC1XslRr75Kgq26Gifb8xbzJcWzebY7gKKu0z9g8NhmjeVX/BiQtPUf7mhSIjy6tx4OpDTIty5oLFEgypkox+c2Hbd0LSkFgUS0m1tnIHPikXVoQ9BBembKaYJEA==; 5:+WN0gpHB3Y5WPxI3quUmfEJGuzQkm8jUzUO9Zp8fEYzr3Xubj6n0ogX9JUaXZB4NyUyPmyNsDenSzfOpk64uH67Ne5/bDO/iZABBvjE0B3lCz2O1APSSdYz5+epNALea0rmSrO9Bde+2oQWuLAZ/mWSnk1tkuHLneHwUTt95C8o=; 7:4NkJ4/2XA83xN2Ut0REDHzDNA1cL+D+1rVjbqiZAYnu8jLK5k5VYG1VqAvl6xjcy3kPzD0zlGLIBEBaycpwKoHF4R1U8AXBwZaN2oU3+He1pum3FZNck2ujcGZ/V2B3Mt2Kobmej0nOuZKh7M/kpnYWZUkYsTbNHdBtlWuCL54N45qEtytLGLwTXfsy+w0Cda01fgBvlXBi8LabANcha+jTc14hPN2iwV0BomdUCCvbYVfDOyTqf1WmfD6d6rt1T SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Aug 2018 14:18:28.2300 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 978afa20-0a8a-44bb-b907-08d5fe02fb09 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR07MB4995 Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status 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: , X-List-Received-Date: Thu, 09 Aug 2018 14:18:33 -0000 -----Original Message----- > Date: Thu, 9 Aug 2018 13:14:40 +0000 > From: "Van Haaren, Harry" > To: "Elo, Matias (Nokia - FI/Espoo)" > CC: "dev@dpdk.org" , Jerin Jacob > > Subject: RE: [dpdk-dev] eventdev: method for finding out unlink status > > > From: Elo, Matias (Nokia - FI/Espoo) [mailto:matias.elo@nokia.com] > > Sent: Wednesday, August 8, 2018 11:05 AM > > To: Van Haaren, Harry > > Cc: dev@dpdk.org; Jerin Jacob > > Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status > > > > > > >>>>>>> > > >>>>>>> I think the end result we're hoping for is something like pseudo > > code below, > > >>>>>>> (keep in mind that the event/sw has a service-core thread running > > it, so no > > >>>>>>> application code there): > > >>>>>>> > > >>>>>>> int worker_poll = 1; > > >>>>>>> > > >>>>>>> worker() { > > >>>>>>> while(worker_poll) { > > >>>>>>> // eventdev_dequeue_burst() etc > > >>>>>>> } > > >>>>>>> go_to_sleep(1); > > >>>>>>> } > > >>>>>>> > > >>>>>>> control_plane_scale_down() { > > >>>>>>> unlink(evdev, worker, queue_id); > > >>>>>>> while(unlinks_in_progress(evdev) > 0) > > >>>>>>> usleep(100); > > >>>>>>> > > >>>>>>> /* here we know that the unlink is complete. > > >>>>>>> * so we can now stop the worker from polling */ > > >>>>>>> worker_poll = 0; > > >>>>>>> } > > >>>>>> > > >>>>>> > > >>>>>> Make sense. Instead of rte_event_is_unlink_in_progress(), How about > > >>>>>> adding a callback in rte_event_port_unlink() which will be called on > > >>>>>> unlink completion. It will reduce the need for ONE more API. > > >>>>>> > > >>>>>> Anyway it RC2 now, so we can not accept a new feature. So we will > > have > > >>>>>> time for deprecation notice. > > >>>>>> > > >>>>> > > >>>>> Both solutions should work but I would perhaps favor Harry's approach > > as it > > >>>>> requires less code in the application side and doesn't break backward > > >>>>> compatibility. > > >>>> > > >>>> OK. > > >>>> > > >>>> Does rte_event_port_unlink() returning -EBUSY will help? > > >>> > > >>> It could perhaps work. The return value becomes a bit ambiguous though. > > E.g. how > > >>> to differentiate a delayed unlink completion from a scenario where the > > port & queues > > >>> have never been linked? > > >> > > >> Based on return code? > > > > > > Yes, that works. I was thinking about the complexity of the implementation > > as it would > > > have to also track the pending unlink requests. But anyway, Harry is > > better answering > > > these questions since I guess he would be implementing this. > > > > > > Hi Harry, > > > > Have you had time to think about this? > > > Hey, Yes I'm just collecting my thoughts at the moment, I see a few small quirks; > > 1) I see the "return -EBUSY from port_unlink()" solution as overloading the rte_event_port_unlink() API. > We lose some self-documenting semantics of the code, see the following snippet @ 1) marker. > > 2) If some unlinks fail, and others are in progress, we cannot describe that in a single return. > See 2) marker in code below. > > > int ret = rte_event_port_unlink(dev, port, queues[], nb_queues); > while (ret == -EBUSY) { > // 1) what args to pass here? It looks like we want to unlink again? The same arguments. > // 2) some unlinks fail, and others are -EBUSY: There is no appropriate ret code in that case > ret = rte_event_port_unlink(...); It is going to be boolean right? like rte_event_port_unlink_in_progress(), So do we need additional return code to express partially completed? > } I was thinking like this, while (rte_event_port_unlink() == -EBUSY) { rte_delay(); } > > > Contrast that to the following, which I feel is simpler and more descriptive: > > int ret = rte_event_port_unlink(dev, port, queues[], nb_queues); > > while (rte_event_port_unlink_in_progress(dev, port) > 0) > rte_delay(); > > > Here the port_unlink() call can sanity-check the unlinks, and return -EINVAL if invalid requests, > and we can detect other unlinks in progress too using the explicit API. > > Regarding adding an API / function-pointer, is there actually a measurable cost there? > Are we willing to sacrifice code-readability and self-documentation? I am fine either approach, at minimum, you can still return -EBUSY so that loop look like this, int ret = rte_event_port_unlink(dev, port, queues[], nb_queues); while (ret == -EBUSY && rte_event_port_unlink_in_progress(dev, port) > 0) rte_delay(); So that, rte_event_port_unlink_in_progress() wont be called for other drivers for normal cases. # Other than that, I am still not able to understand, why not application wait until rte_event_port_unlink() returns. # What in real word use case, application can, do other than waiting to complete rte_event_port_unlink(). If we try to put some logic in like, while (rte_event_port_unlink_in_progress(dev, port) > 0){ do_something(); } The do_something() will not be called in some platform at all. # Any idea on what will be the real world use case, where rte_event_port_unlink() called in fastpath? > > -Harry