From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0078.outbound.protection.outlook.com [104.47.37.78]) by dpdk.org (Postfix) with ESMTP id 5AC7B1B2D5 for ; Sat, 21 Oct 2017 17:05:35 +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; bh=cGhhO7jtTzasQ46toR56bpfo74xHDIV5MeMlvR3FJ24=; b=KGQtKXgzrmoXv9Sis7v36jdxAU3Y9WdF19iCaYN9PVx5djTzy4NAxl4ycuiY2mK2JIfEOEpC2MrC3r2gZ9+aUlYDQPBig9lbCZ9i6aQ2jv7GRJ/k83VApy4UjHRdysNUjimFM/3xYOrV1TQFRS+cn8+KquMvLj8FYRyP4uOjjvk= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; Received: from jerin (171.76.118.225) by CY1PR07MB2522.namprd07.prod.outlook.com (10.167.16.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Sat, 21 Oct 2017 15:05:31 +0000 Date: Sat, 21 Oct 2017 20:35:11 +0530 From: Jerin Jacob To: "Van Haaren, Harry" Cc: Pavan Nikhilesh Bhagavatula , "dev@dpdk.org" Message-ID: <20171021150510.GA7253@jerin> References: <1507814147-8223-1-git-send-email-pbhagavatula@caviumnetworks.com> <20171020103032.GA7404@PBHAGAVATULA-LT> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Originating-IP: [171.76.118.225] X-ClientProxiedBy: BM1PR01CA0081.INDPRD01.PROD.OUTLOOK.COM (10.174.208.149) To CY1PR07MB2522.namprd07.prod.outlook.com (10.167.16.13) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ed776871-3e5e-4ea6-8cff-08d518952d66 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:CY1PR07MB2522; X-Microsoft-Exchange-Diagnostics: 1; CY1PR07MB2522; 3:vR0TVEycLNYfSfvwKoUjOfZe2nLy6Pdmjv4E9JSxc11qEY1VVS0G+JoQl7ljTB9CSF45LMEBcX2RHbWt4BWS9pzR7Wi9jucreBIeIFmPejyVgpYqV1Bdr8L+mqOoWwUDsknXoi14cRFgVU1XNYDr5aiFBfYP9TwyPHxx9gDBLEeUaCDgVbHlnVEHgn8966o0oBd+FkvcWBWqkJkvG7V8ksxM81HVshydRsGraLgiJjsF+1xzcVhWthlYyNdoGkRU; 25:k05NBFN4T4vak36adTlxFwK1H9DC+bESwezv1asfMwNhyY0YOVQC9nNO12y5j95YvxzWRL0L2yU5L/ma5GlEHmZ7TBK8KMNakllplb1vd4vNVwLeceiKJCJ9qqeRBxy8GAXewsoPHabVKh2kfQgXxGYav0I2GLo27GFzzagDJFqBGS6MatflcBcaaqf5MxmSQGFHdJTN5BjUye+E4ABTkggt6d6aHGS8W2y17yaQam/tfLueYoBIT9ba21STWlg1+jVUX7SwuAmMgfBgH41P0iJ8lgTMzFgGvz0IOdHPF5yLPPrCqHOpz/OjjN8mzrb736BbAVJYn9EYx/bq+oetJg==; 31:wNAdw1rz1NepwVQu7qVkdvCxRRCbyVNHWWBPW6UXjdoizZMXwvf9CTi4WttAYaUXSCl5XqCtplWW1gBRR8pgRoysJ5s5uUbYAo5zgb6Tf3JoYzFtmayNx4SiBHE1ErQNg06eUMG/fLYwg3YNaINqs9hwICGStV6Jk82QXTnOnjzqhFRJpKrVBEbjmxhKYM2xYIqOysDSmW5K7E+5kbk1MKQ0R2TlW+4lAoMvFY4izMQ= X-MS-TrafficTypeDiagnostic: CY1PR07MB2522: X-Microsoft-Exchange-Diagnostics: 1; CY1PR07MB2522; 20:QnZnpOzMRp1qZTJ86GcJZNP/WhDS+f1yHaQJlsJvy6h8YGSA/0KP+dzdUvZx+uCd9OgdyM8mHjm+1bIOHO84r0UtgLDwDd717wBeAGPfZSbKbUv09JO5GdgXJXDOsmVVEYalkIgwY/i8hloTT9JQ79w3QVNnt0+GV4GQhjuh2aW0sVb9glOBBbaXMfYfckcAtMEwJH6i8aIny15wG5zWzJ50VvhtLcf87t52xtZch/iyZideq5MeyOnpPubQNsv53SkGBLJ8P51634UbTkawzPnIFzz2CsRXsBv4sbsImFkCTbYV+fahHyDuuhMjeoAZZqACGPSCM/Hh0lAdIv2LkbZMyR1fXgaaxYgJMC8FiiyAEza0WiR/U5XPgMfzHhnXML11fyllA7CcmeoBFG96C/AU/K8OR8TJba2MihrDKRXdP/TPf7IvFsGHP9gRTinm6pLhyMbyHx9Kp16tpF28oHJbp3hKF3DWfn8t0BGpA1cU1Xt2yUYIMzlbR8DLxLafh2sCDpXM7mQbaSS3XnoKknrK83DhdB0Sr9MbFAoyCVaIZFMybe+0Hj7KrbnqIav5qcx2H7GQGqnHyg4AW1ErQtH1rhn9iyoAJObevnr0MCM= X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(185117386973197)(228905959029699); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(100000703101)(100105400095)(3002001)(10201501046)(3231020)(6041248)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR07MB2522; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR07MB2522; X-Microsoft-Exchange-Diagnostics: 1; CY1PR07MB2522; 4:xmJ1MSVYEh2M/WwkRBPOal9oJCdnSrLOQiof3bLbuAGMb0yFXIp+utw7raNrA+mpswT5hipNxiiA7AuTwVfv32RvYNRsUZp44YajTgBvWxDtNeYa82npsgdyW5EX/iSiAxvSLxyh0+JGPP0HZ7a4P0/YnpABPHdqBhPiv8vQNe+Rjy2vgVSdcXxVPR+/ZLZQmcagdq/gaCSU2gugZkJY6g6lF6ZBkbxFBVerdiYdCW4JgjmS8/86/NOHQcW1ywS5aoDjV8mxi8owDwmRbLc02jgPyHMOP3USIlmZJaVgZ8z+BTrx8jgTWCzNk5AW80MrdgNDmFSZJ5QXVxYqH/DRXKX8wOo1T4Z2XV8U8heVK1Om6TkV6SxB/H1qQwftcUxW X-Forefront-PRVS: 046753C63C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(24454002)(199003)(76104003)(189002)(13464003)(2950100002)(6916009)(6666003)(68736007)(229853002)(42882006)(8936002)(16526018)(8676002)(97736004)(305945005)(7736002)(50466002)(189998001)(33716001)(2906002)(3846002)(6116002)(23726003)(83506002)(1076002)(5660300001)(50986999)(76176999)(54356999)(316002)(54906003)(101416001)(58126008)(16586007)(93886005)(33656002)(25786009)(105586002)(66066001)(106356001)(478600001)(4326008)(53546010)(81156014)(47776003)(81166006)(55016002)(72206003)(53936002)(6496005)(6246003)(9686003)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR07MB2522; H:jerin; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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; CY1PR07MB2522; 23:7I3w1GtnL6DNtiIJVVTCP4HWRsXHyw4KAp4jMQBGI?= =?us-ascii?Q?gI/g1R5BtQCoTReg9jh6TDCUX8zGSaEp3u0XrIvIo6EfgFlI5bMi8WbXEmch?= =?us-ascii?Q?xHZHmvKM9NpCvEB3dhIF6xthkqPSYfjsb/Wmn0+HYpQPfgUHOH/1ejNSLAzt?= =?us-ascii?Q?e3cNVwQMJZGNmuvQ5V9Usnyg3D36+5gwAefzAlR8+xvM6gmeMIWUQR+bLbD6?= =?us-ascii?Q?wRPtv+3Qzt3MLAiJ/6oT/Ob+rmcyRbJazLs3K5oevDzYGFLS337IgAV5/GC2?= =?us-ascii?Q?EWSZSHFpShNxUPJ/CDaBcFzN+RHYyM3vnZvwOQVH2UqKU3dQz9nXo+4K+Z+2?= =?us-ascii?Q?9vcT/FsmsZGL/SbXbAOJTNH/evzu/Gwg/r9IWcqzsmun3pH8YjHIqPTNy3pX?= =?us-ascii?Q?58iKYJ1M1eoS+N4idrQOT7jNtyqQE42Hh/WdRvGW6oZ3ahRdlpY8uPHtfBFT?= =?us-ascii?Q?VtiPUha9NuhqoIPNNailMnwwOx05cqPlvmhIKAl/PEQ5wMN2knw2JvYEOIgy?= =?us-ascii?Q?XEnN58ZljexMs5izXIwC3YsuNbTltnpyb9lKkQAo52vcmPzyCOSfFB+N9BLh?= =?us-ascii?Q?LjxGeDnXxggzgwjA1ekirS9jCmrwEks1tejoXmPujAxbTqdPnd4ANSagZTGy?= =?us-ascii?Q?ziUiTzQcSn5LRV+u1mnK8Ga/OUY/AZ2TIp8bV7Z522b7azCWnRsi33FZJf5j?= =?us-ascii?Q?wM614AL8fwHgeiK9jkxSOBzbAGYEHXKzkxs+xHtOKYJDbDx1XM0iGD3Sep1v?= =?us-ascii?Q?TZkbIQzwQMm8eCZy9jrNSXgP3nGR7izyE2XeVmIouuJ1/RTcCteBEX6mKEHi?= =?us-ascii?Q?zQWGcnDNZtBwUzxsvCS+iEVaJ6vISPz94ZK08P8KuW3IqBVpWwG1n2DRB9L8?= =?us-ascii?Q?HPFzt4Wt70zS4QqBaClQzbPrSI9JhP5WNUgnt5tU+ycL8UnrPZeI8nfA8PtB?= =?us-ascii?Q?DYYr+MWiMq7LjRQpCGSzcPJeFJWAZf18kSu2fTwBeeYLqloQULS6OD45z5gb?= =?us-ascii?Q?id/4tdLS8M2NqhPfJFaexkuSc3WdraI4y8mnpXCad70qCKDC7VkOv+Ly7GH9?= =?us-ascii?Q?BGhrjFmtP1OOEqNxVD0/2WxbmRPCHwA8yuGw5/gkn0SHogjXi209Vpyrt8py?= =?us-ascii?Q?uQV3oNh0XOcoBq7IN/GSyVTVwNt/wS+bo7hR11sHFpDeg6DkntRmZ+3JNU6N?= =?us-ascii?Q?V5YiPjdLOEDHDJcmbIK++iyyDJl5QHeVPQtYyg5BGAPjVIEjJ2o11EJZzAnr?= =?us-ascii?Q?0muNzuwTgmHE8uQkvTJFGd9urxrBQa2RTfg4rqo+FOP4HkWO3nftPVB/gxpJ?= =?us-ascii?Q?Q57EK4St6YdM0RsWtg2tWk=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR07MB2522; 6:OeIQPaPaW9Ph/XMHFnBeSTomItNV8eMvfgC3g2F6BQNq06AbUZ98dfq1Hw8NiXOFqPj46N/45im2Xo/ivrDI6POogASD8DdUBCkjVs1j32+vEB7CIm5bPzDTtCFLpUoHUpNzqthREGWAI8zjUI7GStkgt+JlZ31cCqS69/9DijfKpEmOV+maVuV0FqzBj1xrTSf883uC9lcfTwc0nqegMAebAzlwt/w8Ybc1KJyJDRr+GDmtbH8/QyS6y26c9+QJniHtZMoXLOI7d9uvUjpPuXK7wbSXVQVV9it62UYcy/Ku+mQEfxamJaf+TDgT2naJ0jdTdDQqVezr3cqowt6spg==; 5:qmECG1qIRPKeKOIYF9kyQ3QBK2VT6qgl6y8nLLaLJXswaJYxKX1DC/amKTHaeFo96bNK00gcg23ggaDyjBll3aRc4jOWyDc1pXLjHElXOICnvkBN+dXFuHCgcOrRmSgNMsMq4stR6kr1kzb8a+YF+A==; 24:oewvNnBSfZI8aho8T55MMn3EpejCjmeSnsAFMuZsNF+Q/vHPfqzEbe52lMMonF5RCMEFy3ajmtD8LedNNjToDmYFHNkJyz8uiW2rAHTYQsI=; 7:rRqxQnSbuVD1dJW3YZTjDI1jRQpYvBnFBnKMmLbnyovbA1f/uey1/povp3qzSXgHPSuO+/6pQbM3JeoZ4A7n0lWBPbfUAcd5aA9z+QmUFKxTgz6kKY/onkvzhGIhA2AVx8BV3gIkmiplsqhA8PK+oNri2wn31TTFFVp5Va6auvRE0SJH3fUimmm3rIPj2hfqK1fjG9H01W3G1QSBWzkOzXhVx87RI5KgnNTx1am8gr0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Oct 2017 15:05:31.7432 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ed776871-3e5e-4ea6-8cff-08d518952d66 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR07MB2522 Subject: Re: [dpdk-dev] [PATCH 1/3] evendev: fix inconsistency in event queue config 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: Sat, 21 Oct 2017 15:05:35 -0000 -----Original Message----- > Date: Fri, 20 Oct 2017 16:38:57 +0000 > From: "Van Haaren, Harry" > To: Pavan Nikhilesh Bhagavatula > CC: "dev@dpdk.org" > Subject: Re: [dpdk-dev] [PATCH 1/3] evendev: fix inconsistency in event > queue config > > > From: Pavan Nikhilesh Bhagavatula [mailto:pbhagavatula@caviumnetworks.com] > > Sent: Friday, October 20, 2017 11:31 AM > > To: Van Haaren, Harry > > Cc: dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH 1/3] evendev: fix inconsistency in event > > queue config > > > > On Fri, Oct 20, 2017 at 09:54:36AM +0000, Van Haaren, Harry wrote: > > > > From: Pavan Nikhilesh [mailto:pbhagavatula@caviumnetworks.com] > > > > Sent: Thursday, October 12, 2017 2:16 PM > > > > To: jerin.jacob@caviumnetworks.com; hemant.agrawal@nxp.com; Van Haaren, > > > > Harry > > > > Cc: dev@dpdk.org; Pavan Nikhilesh > > > > Subject: [dpdk-dev] [PATCH 1/3] evendev: fix inconsistency in event > > queue > > > > config > > > > > > > > With the current scheme of event queue configuration the cfg schedule > > > > type macros (RTE_EVENT_QUEUE_CFG_*_ONLY) are inconsistent with the > > > > event schedule type (RTE_SCHED_TYPE_*) this requires unnecessary > > > > conversion between the fastpath and slowpath API's while scheduling > > > > events or configuring event queues. > > > > > > > > This patch aims to fix such inconsistency by using event schedule > > > > types (RTE_SCHED_TYPE_*) for event queue configuration. > > > > > > True - worth cleaning up. > > > > > > > > > > This patch also fixes example/eventdev_pipeline_sw_pmd as it doesn't > > > > convert RTE_EVENT_QUEUE_CFG_*_ONLY to RTE_SCHED_TYPE_* which leads to > > > > improper events being enqueued to the eventdev. > > > > > > > > Fixes: adb5d5486c39 ("examples/eventdev_pipeline_sw_pmd: add sample > > app") > > > > > > > > Signed-off-by: Pavan Nikhilesh > > > > > > > > > > > > app/test-eventdev/evt_common.h | 21 ------------- > > > > app/test-eventdev/test_order_queue.c | 4 +-- > > > > app/test-eventdev/test_perf_queue.c | 4 +-- > > > > drivers/event/dpaa2/dpaa2_eventdev.c | 4 +-- > > > > drivers/event/sw/sw_evdev.c | 28 +++++------------ > > > > examples/eventdev_pipeline_sw_pmd/main.c | 18 +++++------ > > > > lib/librte_eventdev/rte_eventdev.c | 20 +++++------- > > > > lib/librte_eventdev/rte_eventdev.h | 54 ++++++++++--------------- > > ---- > > > > --- > > > > test/test/test_eventdev.c | 12 +++---- > > > > test/test/test_eventdev_sw.c | 16 +++++----- > > > > 10 files changed, 60 insertions(+), 121 deletions(-) > > > > > > > > diff --git a/app/test-eventdev/evt_common.h b/app/test- > > eventdev/evt_common.h > > > > index 4102076..ee896a2 100644 > > > > --- a/app/test-eventdev/evt_common.h > > > > +++ b/app/test-eventdev/evt_common.h > > > > @@ -92,25 +92,4 @@ evt_has_all_types_queue(uint8_t dev_id) > > > > true : false; > > > > } > > > > > > > > -static inline uint32_t > > > > -evt_sched_type2queue_cfg(uint8_t sched_type) > > > > -{ > > > > - uint32_t ret; > > > > - > > > > - switch (sched_type) { > > > > - case RTE_SCHED_TYPE_ATOMIC: > > > > - ret = RTE_EVENT_QUEUE_CFG_ATOMIC_ONLY; > > > > - break; > > > > - case RTE_SCHED_TYPE_ORDERED: > > > > - ret = RTE_EVENT_QUEUE_CFG_ORDERED_ONLY; > > > > - break; > > > > - case RTE_SCHED_TYPE_PARALLEL: > > > > - ret = RTE_EVENT_QUEUE_CFG_PARALLEL_ONLY; > > > > - break; > > > > - default: > > > > - rte_panic("Invalid sched_type %d\n", sched_type); > > > > - } > > > > - return ret; > > > > -} > > > > > > > > > We should note here, that SCHED_TYPE are integer values: > > > #define RTE_SCHED_TYPE_ORDERED 0 > > > #define RTE_SCHED_TYPE_ATOMIC 1 > > > #define RTE_SCHED_TYPE_PARALLEL 2 > > > > > > While the EVENT_QUEUE_CFG_ types were bitmasks (before being removed in > > this patch) > > > #define RTE_EVENT_QUEUE_CFG_ATOMIC_ONLY (1ULL << 0) > > > #define RTE_EVENT_QUEUE_CFG_ORDERED_ONLY (2ULL << 0) > > > #define RTE_EVENT_QUEUE_CFG_PARALLEL_ONLY (3ULL << 0) > > > #define RTE_EVENT_QUEUE_CFG_SINGLE_LINK (1ULL << 2) > > > > > > > > > I'm not against this change - but we must be careful that if there was any > > bit-masking being used previously, > > > that that will subtly have broken if we change to sched types. I'm > > reviewing with that in mind.. > > > > > > The RTE_EVENT_QUEUE_CFG_ALL_TYPES config flag now means that all > > SCHED_TYPEs > > > are valid. Previously this was contained in the bitmask.. this may lead to > > issues. > > > > > > See patch 2/3, where *only* the schedule_type is read, and returned. What > > if it the "ALL_TYPES" flag is > > > set on the queue? It will be reported wrongly. Currently there is no > > integer value for "ALL_TYPES", > > > so we cannot represent "ALL TYPES" in the return value from get_attr(). > > > > > > Am I explaining my reasoning clearly enough? > > > > > > > Hey Harry, > > > > I do understand what you mean, my initial thought was to include "ALL_TYPES" > > as > > a schedule_type in queue config but this would just complicate things. > > > > As these values are only used in config phase we could have a check to see > > if > > event_queue_cfg is not "ALL_TYPES" and only then return the value of > > sched_type > > else return a error value in case of get_attr(). > > > > I think most of the places this specific check is handled, one such missed > > place would be get_attr(). If we could come to a conclusion to fix it in a > > correct way I will send out a v2. > > > Sure, I see two sane-ish options: > > 1) Return an error code from get_attr(), which actually means "ALL TYPES". Feels a bit weird, because an error value is really a valid return. > > 2) Return UINT_MAX (aka, -1) as the scheduling value. Applications that use/care about the scheduling type must check, others can ignore it. > > I'm not sure which of these is the better/less-bad solution. Opinions? -H Since we have separate get_attr() for RTE_EVENT_QUEUE_ATTR_EVENT_QUEUE_CFG and RTE_EVENT_QUEUE_ATTR_SCHEDULE_TYPE, Aren't we just fine here? Meaning application can really get back the configured queue attributes through RTE_EVENT_QUEUE_ATTR_EVENT_QUEUE_CFG and RTE_EVENT_QUEUE_ATTR_SCHEDULE_TYPE. Which will be in line with the following comment in header files as well. uint8_t schedule_type; /**< Queue schedule type(RTE_SCHED_TYPE_*). * Valid when RTE_EVENT_QUEUE_CFG_ALL_TYPES bit is not set in * event_queue_cfg. Just thought of avoiding a special interpretation for RTE_EVENT_QUEUE_ATTR_SCHEDULE_TYPE? What do you think? >