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 9FE12423AC; Wed, 11 Jan 2023 12:56:11 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8663340691; Wed, 11 Jan 2023 12:56:11 +0100 (CET) Received: from mx0b-00169c01.pphosted.com (mx0b-00169c01.pphosted.com [67.231.156.123]) by mails.dpdk.org (Postfix) with ESMTP id DE34D4014F for ; Wed, 11 Jan 2023 12:56:09 +0100 (CET) Received: from pps.filterd (m0048188.ppops.net [127.0.0.1]) by mx0b-00169c01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 30BAq27V025630 for ; Wed, 11 Jan 2023 03:56:09 -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=jLjf3bx0K7YtHQ625Ew1YBztMkdSs34t5QJEFtU+NlI=; b=QOftYPeTbb2yWYfg4GK7Gzo76WFzG44C1p2P4XVqhXTg2MAD9F10u6xPdlHREJUicpTj 2q8lBFb/eVE3Jh+aJ/H/r7sVtdkDiHFWB0mEWzmEKU3dC/ifgiXBTw/HXb9VtH6929mI 6e7Rl37sKiyCTNNQYljfR+cyPL4yc7pUHKenHdafUL0t0vTCtMDB6UBWQsI7iTrAKKWu c+PSRqrYCw5CoNYzAKQUXRZrFBxXzJvZOGqoDSSTNV1amovc/ARHevKNygzvKzxn1Qdn Y753yNV7wf+g0r9IkCybzq/vY7ReQCQFs3u9y6+UI8VT3HxQeshzCG0QE/UxnpbsftV+ Nw== Received: from mail-pj1-f69.google.com (mail-pj1-f69.google.com [209.85.216.69]) by mx0b-00169c01.pphosted.com (PPS) with ESMTPS id 3n1k4tsetj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 11 Jan 2023 03:56:09 -0800 Received: by mail-pj1-f69.google.com with SMTP id pi14-20020a17090b1e4e00b0021d20da7a51so11117295pjb.2 for ; Wed, 11 Jan 2023 03:56:08 -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=jLjf3bx0K7YtHQ625Ew1YBztMkdSs34t5QJEFtU+NlI=; b=ZTApLun4krvVzn/sSaDJyAac4lSO2f3Pd3a1NvUlQnOeuLrMrkvXX6a1A0eRS+AKo2 2awn5hKZiBHLJnr15TzzO3PGNdn9381AFWcOkFIsADqy8gE4y5heRomQYTUbYyadqPHo 4OsFGS1yxcvu388iQMmnAdQe3pvCUFFmZiuqj/yjqGa7TzK4QpjPthFcetJKuwOMLm4K XnwcvH8/wQmn5g5L9lcb0qGSRwUJcc30nZF0bU+JROF0he+MriHiTdXB5uI9W8J11+8x RVsdG7bHl175X6kCtobA7FnpjhQ9Z9gWoiLqgcJ94rNsU0A7+LQ/VNVCvlaCsJJw8mZ8 5CtQ== 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=jLjf3bx0K7YtHQ625Ew1YBztMkdSs34t5QJEFtU+NlI=; b=flnrrrhryu8HjLD/tWOEVyN0wjZYmBRW+f8TRYJQSaWIa4va3zFViHlvHRmYgCtrUr G8YY5I0Ys9s4HWktWaUoAaehrha26oAZcCu9vcxnoBOyHGAm++uNU2LkhqqSQtTXkFjd HRBHOfYAdeePMrt+6IQXoUaKaY+9f+dG8J3R7YEimT95E39DRGTGZR1K3vW746RxoYJg V0AfQ9a5HQvU/ym1FV29ZkT7Ao+ymy3z7B9dwgpjMURQYK49xDAUjKZP1N78LpvYMJH8 BqfLiaEUywt3Jmw90gB2NX9boGieF6nEqpe3sxS8+4+zfcFtLVGpXQKLjw17c0224qya 6itg== X-Gm-Message-State: AFqh2koGYiqJ/B3DPf/hkfsTH43KW2/5neuOjlDQGC9lJDuqawKifDrH IqI8TQJ/UmwR70T1CRottq17j3CS0nvTD9V8WpHWBBzwXVWc1IKX8zknWR2kOcfvIf8Cmk3X0ms yuLeIlu0ks5XmbEyNMyw= X-Received: by 2002:a63:c00d:0:b0:478:dacf:9e40 with SMTP id h13-20020a63c00d000000b00478dacf9e40mr4460773pgg.449.1673438167560; Wed, 11 Jan 2023 03:56:07 -0800 (PST) X-Google-Smtp-Source: AMrXdXsOHzfIO9oWk8NHbH7twUtYe3ZD+pA36L+BdSta+9CnLduI8aMcRTzg7Lwxn30nOdB8qoIZk0Tn4ml8gyUPqpo= X-Received: by 2002:a63:c00d:0:b0:478:dacf:9e40 with SMTP id h13-20020a63c00d000000b00478dacf9e40mr4460772pgg.449.1673438167125; Wed, 11 Jan 2023 03:56:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Venky Venkatesh Date: Wed, 11 Jan 2023 03:55:56 -0800 Message-ID: Subject: Re: [2nd Try]:Re: Traffic Management API Questions To: "Singh, Jasvinder" Cc: "dev@dpdk.org" Content-Type: multipart/alternative; boundary="00000000000081f3ec05f1fbafe4" X-Proofpoint-ORIG-GUID: u5kJ2gWQvYM7Zq2jn4rJiwJGvEivmyag X-Proofpoint-GUID: u5kJ2gWQvYM7Zq2jn4rJiwJGvEivmyag X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2023-01-11_05,2023-01-11_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 spamscore=0 adultscore=0 mlxscore=0 lowpriorityscore=0 suspectscore=0 priorityscore=1501 mlxlogscore=999 malwarescore=0 impostorscore=0 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2301110088 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 --00000000000081f3ec05f1fbafe4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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: "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? - If it can be a heterogeneous set of ports, is the scheduling across those ports *weighted* round robin as opposed to round robin? - Are Speeds other than 1/10/40 GbE not supported? - I suppose this heterogeneous mix of port speeds is implemented by playing with the weights across ports, correct? - If so, what problem do you foresee if we provide arbitrary bandwidth ports by regulating the above weights? - 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? Thanks -Venky On Tue, Jan 10, 2023 at 2:54 AM Singh, Jasvinder 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 > > > > --00000000000081f3ec05f1fbafe4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jasvinder,
Thanks for the detailed answers. Our nee= d is to have shaping at the port level as well. I am trying to see what wou= ld be the way 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 ports a= re scheduled in round robin order with all ports having equal priority". Questions:
    • Do all the ports have to be of the same sp= eed OR can it be a heterogeneous set of port speeds?
    • If it can = be a heterogeneous set of ports, is the scheduling across those ports=C2=A0= weighted round robin as opposed to round robin?
    • Are S= peeds other than=C2=A0=C2=A01/10/40 GbE not supported?=C2=A0
    • I supp= ose this heterogeneous=C2=A0mix of port speeds is implemented by playing wi= th the weights across ports, correct?
    • If so, what problem do you fo= resee if we provide arbitrary bandwidth ports by regulating the above weigh= ts?
  • 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 amenable is the current implementation to that?
Do ei= ther 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?=C2=A0
Thanks
-Venky

On Tue, Jan 10, 2023 at 2= :54 AM Singh, Jasvinder <jasvinder.singh@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: 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

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 shaping: single/dual rate,=C2=A0private= (per node) and shared (by=C2=A0multiple nodes) shapers" are supported. However it appears that the code supports only=C2=A0sing= le=C2=A0rate shapers. Is my understanding correct?=C2=A0<= /p>

[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.

<= span>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=

<= span>o=C2=A0=C2=A0=C2= =A0 However, if my understanding is correct, can th= e authors clarify the nature of issues they ran into in supporting dual rat= e (which thus prevented 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 eve= ry 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 my understanding and if it is accurate, the reasons from the author for not supporting it)<= u>

[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 n= umber of levels of QoS 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 sup= pose is built on lower level building blocks including the TM API) expose t= he entire capabilities of the TM API (e.g. dual rate shapers, shapers at po= rt 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 on top of what TM API imposes= . Can someone pls confirm 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=

--00000000000081f3ec05f1fbafe4--