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 306D2A0487 for ; Tue, 2 Jul 2019 11:32:19 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D23F45B3C; Tue, 2 Jul 2019 11:32:16 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id C3DBE5B3C for ; Tue, 2 Jul 2019 11:32:14 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jul 2019 02:32:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,442,1557212400"; d="scan'208";a="338901621" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga005.jf.intel.com with ESMTP; 02 Jul 2019 02:32:12 -0700 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.140]) by IRSMSX101.ger.corp.intel.com ([169.254.1.80]) with mapi id 14.03.0439.000; Tue, 2 Jul 2019 10:32:12 +0100 From: "Singh, Jasvinder" To: "Dumitrescu, Cristian" , "dev@dpdk.org" Thread-Topic: [PATCH v2 00/28] sched: feature enhancements Thread-Index: AQHVMD31k05lkMdtDky2lrFImkCXWKa3BAPQ Date: Tue, 2 Jul 2019 09:32:11 +0000 Message-ID: <54CBAA185211B4429112C315DA58FF6D3FD6BA74@IRSMSX103.ger.corp.intel.com> References: <20190528120553.2992-2-lukaszx.krakowiak@intel.com> <20190625153217.24301-1-jasvinder.singh@intel.com> <3EB4FA525960D640B5BDFFD6A3D891268E8B8C63@IRSMSX108.ger.corp.intel.com> In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891268E8B8C63@IRSMSX108.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiM2I1OTI1NTUtYzgwNi00M2U4LTlkNmEtZmRjYTdmMzJjNWJmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiUDNybStWSjFvNkMwbHk4VEZsWlZlVk5mNkJKcUF6aWNRTHpnSG95V2N2eVRkSVh5MUdpNWQySDJ1b05hTzMyWCJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [163.33.239.180] 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" > -----Original Message----- > From: Dumitrescu, Cristian > Sent: Monday, July 1, 2019 7:51 PM > To: Singh, Jasvinder ; dev@dpdk.org > Subject: RE: [PATCH v2 00/28] sched: feature enhancements >=20 > Hi Jasvinder, >=20 > Thanks for doing this work! Finally a man brave enough to do substantial > changes to this library! Thanks for the words, Cristian! Hope these additions increase the utility o= f library. >=20 > > -----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 > > > > This patchset refactors the dpdk qos sched library to add following > > features to enhance the scheduler functionality. > > > > 1. flexibile configuration of the pipe traffic classes and queues; > > > > Currently, each pipe has 16 queues hardwired into 4 TCs scheduled wi= th > > strict priority, and each TC has exactly with 4 queues that are > > scheduled with Weighted Fair Queuing (WFQ). > > > > Instead of hardwiring queues to traffic class within the specific pi= pe, > > the new implementation allows more flexible/configurable split of pi= pe > > queues between strict priority (SP) and best-effort (BE) traffic cla= sses > > along with the support of more number of traffic classes i.e. max 16= . > > > > All the high priority TCs (TC1, TC2, ...) have exactly 1 queue, whil= e > > the lowest priority BE TC, has 1, 4 or 8 queues. This is justified b= y > > the fact that all the high priority TCs are fully provisioned (small= to > > medium traffic rates), while most of the traffic fits into the BE cl= ass, > > which is typically oversubscribed. > > > > Furthermore, this change allows to use less than 16 queues per pipe = when > > not all the 16 queues are needed. Therefore, no memory will be alloc= ated > > to the queues that are not needed. > > > > 2. Subport level configuration of pipe nodes; > > > > Currently, all parameters for the pipe nodes (subscribers) configura= tion > > 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-classe= s, > > etc. > > > > The new implementation moves pipe nodes configuration parameters fro= m > > port level to subport level structure. Therefore, different subports= of > > 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. > > > > 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 > > > > 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 > > > > Lukasz Krakowiak (1): > > sched: add release note > > > > 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(-) > > > > -- > > 2.21.0 >=20 > This library is tricky, as validating the functional correctness usually = requires > more than just a binary pass/fail result, like your usual PMD (are packet= s > coming out? YES/NO). It requires an accuracy testing, for example how clo= se is > the actual pipe/shaper output rate from the expected rate, how accurate i= s the > strict priority of WFQ scheduling, etc. Therefore, here are a few accurac= y tests > that we need to perform on this library to make sure we did not break any > functionality, feel free to reach out to me if more details needed: I completely agree that we need to validate the accuracy by performing different tests as suggested below. We have performed few of them during de= velopment and found results within tolerance.=20 > 1. Subport shaper accuracy: Inject line rate into a subport, limit subpor= t rate to > X% of line rate (X =3D 5, 10, 15, ..., 90). Check that subport output rat= e matches > the rate limit with a tolerance of 1% of the expected rate. > 2. Subport traffic class rate limiting accuracy: same 1% tolerance=20 3. Pipe > shaper accuracy: same 1% tolerance=20 All above three tests are conducted successfully. 4. Pipe traffic class rate limiting accuracy: > same 1% tolerance 5. Traffic class strict priority scheduling 6. WFQ for = best > effort traffic class These tests are in progress. =20 > On performance side, we need to make sure we don't get a massive > performance degradation. We need proof points for: > 1. 8x traffic classes, 4x best effort queues 2. 8x traffic classes, 1x be= st effort > queue 3. 4x traffic classes, 4x best effort queues 4. 4x traffic classes,= 1x best > effort queue We have done performance measurement all above cases, and performance was f= ound slightly low (between 0.65% -2.6%) compared to existing version.=20 > On unit test side, a few tests to highlight: > 1. Packet for queue X is enqueued to queue X and dequeued from queue X. This is done. > a) Typically tested by sending a single packet and tracing it through the= queues. Yes, done. > b) Should be done for different queue IDs, different number of queues per > subport and different number of subports. This need to be included, will include this in unit tests. > I am sending some initial comments to the V2 patches now, more to come > during the next few days. >=20 > Regards, > Cristian