From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 74DE9423F0; Mon, 16 Jan 2023 15:00:08 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 58B4840691; Mon, 16 Jan 2023 15:00:08 +0100 (CET) Received: from mx0b-00169c01.pphosted.com (mx0b-00169c01.pphosted.com [67.231.156.123]) by mails.dpdk.org (Postfix) with ESMTP id 085A040042 for ; Mon, 16 Jan 2023 15:00:06 +0100 (CET) Received: from pps.filterd (m0281122.ppops.net [127.0.0.1]) by mx0b-00169c01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 30G9KrKV014091 for ; Mon, 16 Jan 2023 06:00:05 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paloaltonetworks.com; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=PPS12012017; bh=HWpE6lBCu+AyAybo8tFh0s+beTuVbqMWAl0G4VAdCfE=; b=qJjxgkRcfiS7huq/lFhv4RIEP3Ut5W0qqC8nam0/P7w5xdBMhOtbmIQu9suutcCS7OLh og7AkG8RVDiE2a28IWg7PbFF0TdA8VUu6rUhZDsptU2N9CWfgMKQe6AV1UwbW7De475F StpuaRL8OIBHGG44dGnpdNDBVxpMjOulx9VGZi6Od7ejmF7Eq/c42tHRQcFyTwlZyJsn 55eRAGQ/CnxdFOoaPuPywXyc3CLhILvMfdJfBkjhXM96WQbszXAWZ/jLx1Un2xQ2PsEy ccSV+h8vJhfJ2OwMqDFw48tmaRniQf5SvPtubaptwDZZwvyeRlCowSb8/0/mOkLGw9Fp 7Q== Received: from mail-pf1-f199.google.com (mail-pf1-f199.google.com [209.85.210.199]) by mx0b-00169c01.pphosted.com (PPS) with ESMTPS id 3n3tvs4hj2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 16 Jan 2023 06:00:04 -0800 Received: by mail-pf1-f199.google.com with SMTP id 80-20020a621453000000b0058952aa1c39so9602425pfu.9 for ; Mon, 16 Jan 2023 06:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paloaltonetworks.com; s=google.paloaltonetworks.com; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=HWpE6lBCu+AyAybo8tFh0s+beTuVbqMWAl0G4VAdCfE=; b=iRnvhF6j/DfsaSoVChka55dHDDYkv6XWPxY4crxQyLG1G1Pk09sL3Kb5RXbKnvuXGR knqQiIzOMMJrSkQfKFQpDJDkSQT14uYqVXmVzTc3/vz8Dd6JLZ7S3PC2cRJBlHs+jhen Pt4c0nF+omxszkdst9QAtzs1hFag/2aIObZBxV3J8BmgvLKjogCqhdoC2Q1dPOk9AqFy mFznuZX0XGbGcl8H+48WeptbjPkPypQcnmVenndON4803zjPqgSVoup6yBKn5b0heTtd /En2MmTkp/ulPjqK/Mylgr0PyD1THS4FgoVYStHfrNs6XcTnxNcG1lsmzNlWeiqb6z26 hIbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HWpE6lBCu+AyAybo8tFh0s+beTuVbqMWAl0G4VAdCfE=; b=v3y0DmVegd/+2uvI9XKlvvwLjLtxCBwX7eL/PudF2yf1myAPED3k8fKxVPsZz97UbK 0VpEZzgimOo2BsEebnsbP8G/R09n9qPdFACXSVYhJcHrBW0H63QvxvhXBhkrTXStlL8L W9B2pedihASNJXKzDU0fAWHBSWhDaknTlH8P289pY5L6sn0/4zwc6PZSVaC6/TcFVd9F 53uWvu5Ch65DH7H5G+QFFgI9WpuIR00Qa2sobAl/qjyjY7Gs8162Qzc05BCD7eZl/XTE j+cgt4ztMT/u0ObKLZ/UE1wHY7zQTbq3QNluz6bGmv76ZHZuFysTW3bDcueA4lXlq3GP bVzw== X-Gm-Message-State: AFqh2krTqJcwyBp9AFUWVUxLIbtqGVaYfrLTtvywd5McDwvN0pr4bU1i FXO0IGtUBfTh5gJ7bXZUhZXPaRxfMfx9KX3L3ZMFPc9wnXJS6Cxlq7oXQOP7PxEiV4TjXsYILcr Z2yXXJ4eb4k6qfJ5xQb8= X-Received: by 2002:a63:40c5:0:b0:480:8458:2f8b with SMTP id n188-20020a6340c5000000b0048084582f8bmr4714197pga.228.1673877603253; Mon, 16 Jan 2023 06:00:03 -0800 (PST) X-Google-Smtp-Source: AMrXdXvTjHtWlyvSffNvq8ttH6hbAZUQalETZLGpTK+86KGez5PSZ5S10TNdYLF0gt4UwHDsLfbnIN2aagmexMXoJLc= X-Received: by 2002:a63:40c5:0:b0:480:8458:2f8b with SMTP id n188-20020a6340c5000000b0048084582f8bmr4714193pga.228.1673877602806; Mon, 16 Jan 2023 06:00:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Venky Venkatesh Date: Mon, 16 Jan 2023 05:59:52 -0800 Message-ID: Subject: Re: [2nd Try]:Re: Traffic Management API Questions To: "Singh, Jasvinder" Cc: "dev@dpdk.org" Content-Type: multipart/alternative; boundary="000000000000e9d81c05f261ff4d" X-Proofpoint-ORIG-GUID: 89tOWJ05-z7pAplGi8G8tC4-bWB8wE26 X-Proofpoint-GUID: 89tOWJ05-z7pAplGi8G8tC4-bWB8wE26 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.923,Hydra:6.0.562,FMLib:17.11.122.1 definitions=2023-01-16_11,2023-01-13_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 phishscore=0 bulkscore=0 lowpriorityscore=0 spamscore=0 impostorscore=0 adultscore=0 mlxlogscore=999 suspectscore=0 mlxscore=0 malwarescore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2301160105 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --000000000000e9d81c05f261ff4d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Jasvinder. I guess we are on the same page. With the design that you mention we run short by 1 level of hierarchy -- which is why I was originally asking for the difficulty of adding a layer. I think I understand your assessment in that regard i.e. it is easier to add a shaped dequeue at the roots in the application as opposed to add an additional layer Pls correct me if I am wrong. Otherwise Thanks for all your inputs -Venky On Mon, Jan 16, 2023 at 3:39 AM Singh, Jasvinder wrote: > Hi Venky, > > > > Please see inline; > > > > Thanks, > > Jasvinder > > > > > > *From:* Venky Venkatesh > *Sent:* Monday, January 16, 2023 8:06 AM > *To:* Singh, Jasvinder > *Cc:* dev@dpdk.org > *Subject:* Re: [2nd Try]:Re: Traffic Management API Questions > > > > Hi Jasvinder, > > Thanks for the insights on the complexity of adding a layer. > > As for the workaround that you suggested using multiple subports, if I > understand it correctly (*pls correct if I misunderstood*) it would not > meet our needs: > > - We require multiple heterogeneous ports (i.e. ports with different > bandwidths -- with no excess sharing since these are port limits). Tha= t > would probably need some shaper attached there too since WRR (at the > application) would share the instantaneous excess among the siblings. > > =C2=B7 As for the 2nd second suggestion (increase the number of subports= ): > our need (*in addition to* multiple ports of different bandwidths at the > top level) is to have 4 more TM layers for a total of 5. I am *not* > looking at the assignment of the terms port/subport/user/pipe etc in the > DPDK documentation -- instead am looking at it as abstract scheduling > (and/or shaping) layers with differing abilities in some layers. So in > order to compensate for the missing shaper at the port level I was planni= ng > to add 1 additional layer (so that what in DPDK documentation is referred > to as subport is actually a port -- since the subport layer has the > property of *not sharing* excess between siblings. With that principle, I > am not clear how adding width to the subport layer (as I understand your > suggestion) would help. > > [JS] =E2=80=93 I was suggesting to assume subports as ports in the existi= ng > implementation and assign fixed bandwidth to each of the subports. By doi= ng > so, you would have multiple subports (re-named as ports) with shaper > attached. Only limitation in such solution is that hierarchy would have > single root node with the bandwidth equal to sum of subports bandwidth an= d > all the subports would be served individually in round robin manner. If i= t > doesn=E2=80=99t suit your requirement, you need to make changes as you s= uggested > above. > > > > Thanks > > -Venky > > > > > > On Wed, Jan 11, 2023 at 9:24 AM Singh, Jasvinder < > jasvinder.singh@intel.com> wrote: > > Hi Venky, > > > > Please see inline; > > > > Jasvinder > > > > *From:* Venky Venkatesh > *Sent:* Wednesday, January 11, 2023 11:56 AM > *To:* Singh, Jasvinder > *Cc:* dev@dpdk.org > *Subject:* Re: [2nd Try]:Re: Traffic Management API Questions > > > > Hi Jasvinder, > > Thanks for the detailed answers. Our need is to have shaping at the port > level as well. I am trying to see what would be the way to accomplish thi= s > given the current limitations of the sched library implementation in this > regard. I see 2 options: > > - The top level (i.e. port level) documentation says the following: > "Output Ethernet port 1/10/40 GbE" and "Multiple ports are scheduled > in round robin order with all ports having equal priority". Questions: > > > - Do all the ports have to be of the same speed OR can it be a > heterogeneous set of port speeds? > > [JS] =E2=80=93 the library supports single port (root node) of the hierar= chy. Each > port can have multiple subports configured using different shaping rates. > If you desire to have multiple ports, each port would have separate > hierarchical tree underneath. Different ports could have different speed. > > o If it can be a heterogeneous set of ports, is the scheduling across > those ports *weighted* round robin as opposed to round robin? > > [JS] =E2=80=93 Scheduling across multiple ports is not supported in curre= nt sched > library. At the application level, one can think of invoking > enqueue/dequeue sched API in round robin or weighted round robin manner. > > - Are Speeds other than 1/10/40 GbE not supported? > > [JS] =E2=80=93 Speeds other than above is supported, for eg. 25G, 50G etc= . > > - I suppose this heterogeneous mix of port speeds is implemented by > playing with the weights across ports, correct? > > [JS] -please see above answers > > - If so, what problem do you foresee if we provide arbitrary bandwidth > ports by regulating the above weights? > > [JS] =E2=80=93 I don=E2=80=99t see any issue. > > - The other alternative would be to add another layer (which has a > shaper) to the hierarchy by mimicking one of the existing layers: how > amenable is the current implementation to that? > > Do either of the above look like workable ideas? Are there any other > approaches where we could accomplish our requirement with minimal changes > to the code logic? > > [JS] =E2=80=93 adding another layer will require considerable work in lib= rary. How > about using multiple subports with different shaping bandwidth where each > subport maintain #subcribers and send traffic out through single physical > port (root node). It will need less effort and library supports multiple > subports under single port (root node). > > > > > > Thanks > > -Venky > > > > On Tue, Jan 10, 2023 at 2:54 AM Singh, Jasvinder < > jasvinder.singh@intel.com> wrote: > > Hi Venky, > > > > Please see inline. > > > > Thanks, > > Jasvinder > > > > > > *From:* Venky Venkatesh > *Sent:* Tuesday, January 10, 2023 8:52 AM > *To:* dev@dpdk.org > *Subject:* [2nd Try]:Re: Traffic Management API Questions > > > > Hi, > > Can someone pls get back on these > > Thanks > > -Venky > > > > On Thu, Jan 5, 2023 at 4:07 AM Venky Venkatesh < > vvenkatesh@paloaltonetworks.com> wrote: > > Hi, > > I was looking at the DPDK Traffic Management API. I wanted to clarify som= e > things that I understand from the code (for software based TM > implementation (at 20.11)) vs the documentation. > > =C2=B7 The documentation says "Traffic shaping: single/*dual rate= **,* private > (*per node*) and shared (by *multiple nodes*) shapers" are supported. > However it appears that the code supports only *single *rate shapers. Is > my understanding correct? > > [JS] =E2=80=93 Yes, TM API supports single and dual rate shapers, private= ly per > node as well as shared across multiple nodes. However, DPDK QoS scheduler > library implements single rate shaper at nodes. > > o If not, pls point me to where dual rate shaping is supported in the > software based TM implementation code. > > o However, if my understanding is correct, can the authors clarify the > nature of issues they ran into in supporting dual rate (which thus > prevented them from implementing it)? > > [JS] =E2=80=93 There isn=E2=80=99t any issue except more complexity. Auth= or can rework the > library to implement the dual rate shapers for the desired nodes dependin= g > upon the requirement. > > =C2=B7 The documentation comment above sounds like every node can= have > shapers. However it appears that the code does not support shaping at the > port level. Again the same questions as above(regarding the accuracy of m= y > understanding and if it is accurate, the reasons from the author for not > supporting it) > > [JS] =E2=80=93 Implementation supports shapers at subport (group of pipes= ) and > pipe level. The bandwidth available at the port level is distributed amon= g > the subports with the condition that aggregate bandwidth of subports shou= ld > not exceed the port bandwidth. Each subport buffers and shape the traffic > from the pipes depending upon the port bandwidth allocated to it. > Implementation doesn=E2=80=99t support distribution of unused bandwidth o= f one > subport to another subport. However, one can modify this behaviour if > needed. > > =C2=B7 At the level of the TM API (*and* the associated software = TM > implementation) are there any restrictions on the number of levels of QoS > hierarchy we can construct? > > [JS] =E2=80=93 TM API doesn=E2=80=99t restrict the number of QoS schedule= r levels and > generic enough to work with hierarchical schedulers with any number of > levels. The current dpdk sched library implementation supports fixed 5 > level scheduler hierarchy. > > =C2=B7 Lastly, does the QoS framework API (which I suppose is bui= lt on > lower level building blocks including the TM API) expose the entire > capabilities of the TM API (e.g. dual rate shapers, shapers at port level= , > > 4 levels of shaping etc.)? From the reading of the documentation it > appears that there may be restrictions imposed by the QoS framework API o= n > top of what TM API imposes. Can someone pls confirm this (and if so, the > reason for doing so)? > > [JS] =E2=80=93 No, QoS framework API (DPDK sched library) presents only o= ne > flavour of hierarchical scheduler and doesn=E2=80=99t implements all the = features > exposed through TM API. However, more features can be added to library a= nd > configured through TM API. > > > > Thanks > > -Venky > > > > --000000000000e9d81c05f261ff4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Jasvinder. I guess we are on the same page. With th= e design that you mention we run short by 1 level of hierarchy -- which is = why I was originally asking for the difficulty of adding a layer. I think I= understand your assessment in that regard i.e. it is easier to add a shape= d dequeue at the roots in the application as opposed to add an additional l= ayer

Pls correct me if I am wrong. Otherwise Thanks for = all your inputs
-Venky

=
On Mon, Jan 16, 2023 at 3:39 AM Singh= , Jasvinder <jasvinder.sing= h@intel.com> wrote:

Hi Venky,

=C2=A0

Please see inline;

=C2=A0

Thanks,

Jasvinder

=C2=A0

=C2=A0

From: Venky Venkatesh <vvenkatesh@paloaltonetworks.com>
Sent: Monday, January 16, 2023 8:06 AM
To: Singh, Jasvinder <jasvinder.singh@intel.com>
Cc: dev@dpdk.org
Subject: Re: [2nd Try]:Re: Traffic Management API Questions

=C2=A0

Hi Jasvinder,

Thanks for the insights on the complexity of adding = a layer.

As for the workaround that you suggested using multi= ple subports, if I understand it correctly (pls correct if I misundersto= od) it would not meet our needs:

  • We require multiple heterogeneous ports (i.e. ports with different bandwidt= hs -- with no excess sharing since these are port limits). That would proba= bly need some shaper attached there too since WRR (at the application) woul= d share the instantaneous excess among the siblings.

=C2=B7=C2=A0 As for the 2nd second suggestion (increase the = number of subports): our need (in addition to multiple ports of diff= erent bandwidths at the top level) is to have=C2=A0 4 more TM layers for a = total of 5. I am not looking at the assignment of the terms port/subport/user/pipe et= c in the DPDK documentation -- instead am looking at it as abstract schedul= ing (and/or shaping) layers with differing abilities in some layers. So in = order to compensate for the missing shaper at the port level I was planning to add 1 additional layer (so that= what in DPDK documentation is referred to as subport is actually a port --= since the subport layer has the property of not sharing excess between siblings. With that principle, I am not c= lear how adding width to the subport layer (as I understand your suggestion= ) would help.

[JS] =E2=80=93 I was suggesting to assume subports a= s ports in the existing implementation and assign fixed bandwidth to each o= f the subports. By doing so, you would have multiple subports (re-named as ports) with shaper attached. Only limitation in such solution= is that hierarchy would have single root node with the bandwidth equal to = sum of subports bandwidth and all the subports would be served individually= in round robin manner. If it doesn=E2=80=99t suit your =C2=A0requirement, you need to make changes as you suggested abo= ve.

=C2=A0

Thanks

-Venky

=C2=A0

=C2=A0

Hi Venky,

=C2=A0

Please see inline;

=C2=A0

Jasvinder

=C2=A0

From: Venky Venkatesh <vvenkatesh@paloaltone= tworks.com>
Sent: Wednesday, January 11, 2023 11:56 AM
To: Singh, Jasvinder <jasvinder.singh@intel.com>
Cc: dev@dpdk.org
Subject: Re: [2nd Try]:Re: Traffic Management API Questions

=C2=A0

Hi Jasvinder,

Thanks for the detailed answers. Our need is to have= shaping at the port level as well. I am trying to see what would be the wa= y to accomplish this given the current limitations of the sched library implementation in this regard. I see 2 options:

  • The top level (i.e. port level) documentation says the following: "Out= put Ethernet port 1/10/40 GbE" and "Multiple por= ts are scheduled in round robin order with all ports having equal priority". Questions:
    • Do all the ports have to be of the same speed OR can it be a heterogeneous = set of port speeds?

[JS] =E2=80=93 the library supports single port (roo= t node) of the hierarchy. Each port can have multiple subports configured u= sing different shaping rates. If you desire to have multiple ports, each port would have separate hierarchical tree underneath. Differe= nt ports could have different speed.

o= If it can be a heterogeneous set of ports, is the scheduling across = those ports=C2=A0weighted round robin as opposed to round rob= in?

[JS] =E2=80=93 Scheduling across multiple ports is n= ot supported in current sched library. At the application level, one can th= ink of invoking enqueue/dequeue sched API in round robin or weighted round robin manner.

    • Are Speeds other than=C2=A0=C2=A01/10/40 GbE not supported?=C2=A0=

[JS] =E2=80=93 Speeds other than above is supported,= for eg. 25G, 50G etc.

    • I suppose this heterogeneous=C2=A0mix of port speeds is implemented by play= ing with the weights across ports, correct?

[JS] -please see above answers

    • If so, what problem do you foresee if we provide arbitrary bandwidth ports = by regulating the above weights?

[JS] =E2=80=93 I don=E2=80=99t see any issue.

  • The other alternative would be to add another layer (which has a shaper)=C2= =A0=C2=A0to the hierarchy by mimicking one of the existing layers: how amen= able is the current implementation to that?

Do either of the above look like workable ideas? Are= there any other approaches where we could accomplish our requirement with = minimal changes to the code logic?

[JS] =E2=80=93 adding another layer will require con= siderable work in library. How about using multiple subports with different= shaping bandwidth where each subport maintain #subcribers and send traffic out through single physical port (root node). It will nee= d less effort and library supports multiple subports under single port (roo= t node).

=C2=A0

=C2=A0

Thanks

-Venky

=C2=A0

On Tue, Jan 10, 2023 at 2:54 AM Singh, Jasvinder <= ;jasvinder.s= ingh@intel.com> wrote:

Hi Venky,

=C2=A0

Please see inline.

=C2=A0

Thanks,

Jasvinder

=C2=A0

=C2=A0

From: Venky Venkatesh <vvenkatesh@paloaltone= tworks.com>
Sent: Tuesday, January 10, 2023 8:52 AM
To: dev@dpdk.org
Subject: [2nd Try]:Re: Traffic Management API Questions

=C2=A0

Hi,

Can someone pls get back on these

Thanks

-Venky

=C2=A0

On Thu, Jan 5, 2023 at 4:07 AM Venky Venkatesh <<= a href=3D"mailto:vvenkatesh@paloaltonetworks.com" target=3D"_blank">vvenkat= esh@paloaltonetworks.com> wrote:

Hi,

I was looking at the DPDK Traffic Management API. I = wanted to clarify some things that I understand from the code (for software= based TM implementation (at 20.11)) vs the documentation.

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The documentation says "Traffic shapin= g: single/dual rate,=C2=A0private (per node) an= d shared (by=C2=A0multiple nodes) shapers" are supported= . However it appears that the code supports only=C2=A0single=C2=A0rate shaper= s. Is my understanding correct?=C2=A0

[JS] =E2=80=93 Yes, TM API supports single and dual = rate shapers, privately per node as well as shared across multiple nodes. H= owever, DPDK QoS scheduler library implements single rate shaper at nodes.

o= =C2=A0=C2=A0=C2=A0 If not, pls point me to where dual rate shaping is supported in the = software based TM implementation code.=C2=A0

o= =C2=A0=C2=A0=C2=A0 However, if my understanding is correct, can the authors clarify the= nature of issues they ran into in supporting dual rate (which thus prevent= ed them from implementing it)?

[JS] =E2=80=93 There isn=E2=80=99t any issue except = more complexity. Author can rework the library to implement the dual rate s= hapers for the desired nodes depending upon the requirement. =C2=A0<= u>

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The documentation comment above sounds like every node can have shap= ers. However it appears that the code does not support shaping at the port = level. Again the same questions as above(regarding the accuracy of my under= standing and if it is accurate, the reasons from the author for not supporting it)

[JS] =E2=80=93 Implementation supports shapers at su= bport (group of pipes) and pipe level. The bandwidth available at the port = level is distributed among the subports with the condition that aggregate bandwidth of subports should not exceed the port bandwidth.= Each subport buffers and shape the traffic from the pipes depending upon t= he port bandwidth allocated to it. Implementation doesn=E2=80=99t support d= istribution of unused bandwidth of one subport to another subport. However, one can modify this behaviour if needed. =C2= =A0=C2=A0

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 At the level of the TM API (and=C2=A0the associated software = TM implementation) are there any restrictions on the number of levels of Qo= S hierarchy we can construct?

[JS] =E2=80=93 TM API doesn=E2=80=99t restrict the n= umber of QoS scheduler levels and generic enough to work with hierarchical = schedulers with any number of levels. The current dpdk sched library implementation supports fixed 5 level scheduler hierarchy. =C2=A0=C2=A0=C2= =A0

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Lastly, does the QoS framework API (which I suppose is built on lowe= r level building blocks including the TM API) expose the entire capabilitie= s of the TM API (e.g. dual rate shapers, shapers at port level, > 4 leve= ls of shaping etc.)? From the reading of the documentation it appears that there may be restrictions imposed by = the QoS framework API on top of what TM API imposes. Can someone pls confir= m this (and if so, the reason for=C2=A0doing so)?

[JS] =E2=80=93 No, QoS framework API (DPDK sched lib= rary) presents only one flavour of hierarchical scheduler and doesn=E2=80= =99t implements all the features exposed through TM API.=C2=A0 However, mor= e features can be added to library and configured through TM API. =

=C2=A0

Thanks

-Venky=

=C2=A0=

--000000000000e9d81c05f261ff4d--