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 458D1A0487 for ; Mon, 1 Jul 2019 20:51:21 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 38F2D1B9CA; Mon, 1 Jul 2019 20:51:20 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 775AE1B9C8 for ; Mon, 1 Jul 2019 20:51:18 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jul 2019 11:51:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,440,1557212400"; d="scan'208";a="190352929" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by fmsmga002.fm.intel.com with ESMTP; 01 Jul 2019 11:51:16 -0700 Received: from irsmsx155.ger.corp.intel.com (163.33.192.3) by IRSMSX102.ger.corp.intel.com (163.33.3.155) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 1 Jul 2019 19:51:15 +0100 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.46]) by irsmsx155.ger.corp.intel.com ([169.254.14.100]) with mapi id 14.03.0439.000; Mon, 1 Jul 2019 19:51:15 +0100 From: "Dumitrescu, Cristian" To: "Singh, Jasvinder" , "dev@dpdk.org" Thread-Topic: [PATCH v2 00/28] sched: feature enhancements Thread-Index: AQHVK2snZySzyF5oJ0SMW2lado5rhaa2ICsQ Date: Mon, 1 Jul 2019 18:51:14 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D891268E8B8C63@IRSMSX108.ger.corp.intel.com> References: <20190528120553.2992-2-lukaszx.krakowiak@intel.com> <20190625153217.24301-1-jasvinder.singh@intel.com> In-Reply-To: <20190625153217.24301-1-jasvinder.singh@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzg5NzA3MGUtM2EyNi00ZmVlLTg0YTktODZjNmRlZjI0YjZlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiUkE2d1NlaDdCc0ZJOFRsNWNWYW90SG01TllHY2VqTXYyb3J6T0M3ZWU2THlCRlI2RWIraTdONjEzV1NubE9MKyJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 00/28] sched: feature enhancements 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 Jasvinder, Thanks for doing this work! Finally a man brave enough to do substantial ch= anges to this library! > -----Original Message----- > From: Singh, Jasvinder > Sent: Tuesday, June 25, 2019 4:32 PM > To: dev@dpdk.org > Cc: Dumitrescu, Cristian > Subject: [PATCH v2 00/28] sched: feature enhancements >=20 > This patchset refactors the dpdk qos sched library to add > following features to enhance the scheduler functionality. >=20 > 1. flexibile configuration of the pipe traffic classes and queues; >=20 > Currently, each pipe has 16 queues hardwired into 4 TCs scheduled with > strict priority, and each TC has exactly with 4 queues that are > scheduled with Weighted Fair Queuing (WFQ). >=20 > Instead of hardwiring queues to traffic class within the specific pipe= , > the new implementation allows more flexible/configurable split of pipe > queues between strict priority (SP) and best-effort (BE) traffic class= es > along with the support of more number of traffic classes i.e. max 16. >=20 > All the high priority TCs (TC1, TC2, ...) have exactly 1 queue, while > the lowest priority BE TC, has 1, 4 or 8 queues. This is justified by > the fact that all the high priority TCs are fully provisioned (small t= o > medium traffic rates), while most of the traffic fits into the BE clas= s, > which is typically oversubscribed. >=20 > Furthermore, this change allows to use less than 16 queues per pipe wh= en > not all the 16 queues are needed. Therefore, no memory will be allocat= ed > to the queues that are not needed. >=20 > 2. Subport level configuration of pipe nodes; >=20 > Currently, all parameters for the pipe nodes (subscribers) configurati= on > are part of the port level structure which forces all groups of > subscribers (i.e. pipes) in different subports to have similar > configurations in terms of their number, queue sizes, traffic-classes, > etc. >=20 > The new implementation moves pipe nodes configuration parameters from > port level to subport level structure. Therefore, different subports o= f > the same port can have different configuration for the pipe nodes > (subscribers), for examples- number of pipes, queue sizes, queues to > traffic-class mapping, etc. >=20 > v2: > - fix bug in subport parameters check > - remove redundant RTE_SCHED_SUBPORT_PER_PORT macro > - fix bug in grinder_scheduler function > - improve doxygen comments > - add error log information >=20 > Jasvinder Singh (27): > sched: update macros for flexible config > sched: update subport and pipe data structures > sched: update internal data structures > sched: update port config API > sched: update port free API > sched: update subport config API > sched: update pipe profile add API > sched: update pipe config API > sched: update pkt read and write API > sched: update subport and tc queue stats > sched: update port memory footprint API > sched: update packet enqueue API > sched: update grinder pipe and tc cache > sched: update grinder next pipe and tc functions > sched: update pipe and tc queues prefetch > sched: update grinder wrr compute function > sched: modify credits update function > sched: update mbuf prefetch function > sched: update grinder schedule function > sched: update grinder handle function > sched: update packet dequeue API > sched: update sched queue stats API > test/sched: update unit test > net/softnic: update softnic tm function > examples/qos_sched: update qos sched sample app > examples/ip_pipeline: update ip pipeline sample app > sched: code cleanup >=20 > Lukasz Krakowiak (1): > sched: add release note >=20 > app/test/test_sched.c | 39 +- > doc/guides/rel_notes/deprecation.rst | 6 - > doc/guides/rel_notes/release_19_08.rst | 7 +- > drivers/net/softnic/rte_eth_softnic.c | 131 + > drivers/net/softnic/rte_eth_softnic_cli.c | 286 ++- > .../net/softnic/rte_eth_softnic_internals.h | 8 +- > drivers/net/softnic/rte_eth_softnic_tm.c | 89 +- > examples/ip_pipeline/cli.c | 85 +- > examples/ip_pipeline/tmgr.c | 22 +- > examples/ip_pipeline/tmgr.h | 3 - > examples/qos_sched/app_thread.c | 11 +- > examples/qos_sched/cfg_file.c | 283 ++- > examples/qos_sched/init.c | 111 +- > examples/qos_sched/main.h | 7 +- > examples/qos_sched/profile.cfg | 59 +- > examples/qos_sched/profile_ov.cfg | 47 +- > examples/qos_sched/stats.c | 483 ++-- > lib/librte_pipeline/rte_table_action.c | 1 - > lib/librte_pipeline/rte_table_action.h | 4 +- > lib/librte_sched/Makefile | 2 +- > lib/librte_sched/meson.build | 2 +- > lib/librte_sched/rte_sched.c | 2133 ++++++++++------- > lib/librte_sched/rte_sched.h | 229 +- > lib/librte_sched/rte_sched_common.h | 41 + > 24 files changed, 2634 insertions(+), 1455 deletions(-) >=20 > -- > 2.21.0 This library is tricky, as validating the functional correctness usually re= quires more than just a binary pass/fail result, like your usual PMD (are p= ackets coming out? YES/NO). It requires an accuracy testing, for example ho= w close is the actual pipe/shaper output rate from the expected rate, how a= ccurate is the strict priority of WFQ scheduling, etc. Therefore, here are = a few accuracy tests that we need to perform on this library to make sure w= e did not break any functionality, feel free to reach out to me if more det= ails needed: 1. Subport shaper accuracy: Inject line rate into a subport, limit subport = rate to X% of line rate (X =3D 5, 10, 15, ..., 90). Check that subport outp= ut rate matches the rate limit with a tolerance of 1% of the expected rate. 2. Subport traffic class rate limiting accuracy: same 1% tolerance 3. Pipe shaper accuracy: same 1% tolerance 4. Pipe traffic class rate limiting accuracy: same 1% tolerance 5. Traffic class strict priority scheduling 6. WFQ for best effort traffic class On performance side, we need to make sure we don't get a massive performanc= e degradation. We need proof points for: 1. 8x traffic classes, 4x best effort queues 2. 8x traffic classes, 1x best effort queue 3. 4x traffic classes, 4x best effort queues 4. 4x traffic classes, 1x best effort queue On unit test side, a few tests to highlight: 1. Packet for queue X is enqueued to queue X and dequeued from queue X. a) Typically tested by sending a single packet and tracing it through the q= ueues. b) Should be done for different queue IDs, different number of queues per s= ubport and different number of subports. I am sending some initial comments to the V2 patches now, more to come duri= ng the next few days. Regards, Cristian