From: nagurvalisayyad <nagurvalisayyad@bel.co.in>
To: Users <users@dpdk.org>
Subject: DPDK Qos scheduler TC's misbehaviour within a Pipe
Date: Thu, 11 Dec 2025 10:21:10 +0530 [thread overview]
Message-ID: <acec30baa332646e554e3a30b3e8d09a@bel.co.in> (raw)
[-- Attachment #1: Type: text/plain, Size: 2231 bytes --]
Hi,
We are using dpdk-stable-22.11.6 version in our project.
We are facing an issue in our DPDK QoS scheduler example application, we
notice that lower priority traffic (TC2) starves higher priority traffic
if the packet size of the lower priority traffic is smaller than the
packet size of the higher priority traffic.
If the packet size of the lower priority traffic (TC2) is same or larger
than the higher priority (TC0 or TC1), we dont see the problem.
Using q-index within the TC:
Pipe 0 size is 20Mbps
- Q0 (TC0), 1500 byte packets, 5Mbps configured and
- Q1 (TC2), 1400 byte packets, 20Mbps configured
- Total two pipes are configured and traffic is mapped to Pipe 0 TC0 and
TC2
- Only on subport configured.
- TC period is set to 50ms (to support lower rates of around 256Kbps)
In this scenario TC2 consumes all the 20Mbps bandwidth, but as per
priority, TC0 should get 5Mbps and TC2 should get 15Mbps.
If we pump the same size byte packets, then TC0 is getting 5Mbps and TC1
is getting 15Mbps as per priority.
If we stop the TC0 traffic, then the unused 5Mbps from TC0 is getting
used by TC1 and is getting 20Mbps.(as expected).
To further debug, we found in the qos scheduler documentation section
57.2.4.6.3. Traffic Shaping
"
* Full accuracy can be achieved by selecting the value for _tb_period_
for which _tb_credits_per_period = 1_.
* When full accuracy is not required, better performance is achieved
by setting _tb_credits_ to a larger value.
"
In rte_sched.c file, rte_sched_pipe_profile_convert(), the
_tb_credits_per_period _is set to 1 and accordingly _tb_period _is set
according to the rate.
We have increased the _tb_credits_per_period _and_ tb_period _by 10000
times. So that 10000 credis are updated in the token bucket at a time.
With this, TC0 and TC2 are working but not as much accurate as earlier.
And we are having the doubt of how this change will behave for different
rates and different packet sizes.
Can you please help us in setting the optimal value for
_tb_credits_per_period and tb_period, _so that it works well for
different traffic rates and different packet sizes.
Please help us in resolving this issue.
--
Thanks & Regards
Nagurvali sayyad
[-- Attachment #2: Type: text/html, Size: 3553 bytes --]
next reply other threads:[~2025-12-11 4:51 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-11 4:51 nagurvalisayyad [this message]
-- strict thread matches above, loose matches on Subject: below --
2025-12-10 11:44 nagurvalisayyad
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=acec30baa332646e554e3a30b3e8d09a@bel.co.in \
--to=nagurvalisayyad@bel.co.in \
--cc=users@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).