From: Stephen Hemminger <stephen@networkplumber.org>
To: netdev@vger.kernel.org
Subject: Fw: [Bug 216813] New: HFSC: "tc class change" can't remove rt service curve
Date: Fri, 16 Dec 2022 09:24:18 -0800 [thread overview]
Message-ID: <20221216092418.3e898d6f@hermes.local> (raw)
No one has touched hfsc in a long time.
Looks like more of an user interface issue.
Begin forwarded message:
Date: Fri, 16 Dec 2022 09:29:19 +0000
From: bugzilla-daemon@kernel.org
To: stephen@networkplumber.org
Subject: [Bug 216813] New: HFSC: "tc class change" can't remove rt service curve
https://bugzilla.kernel.org/show_bug.cgi?id=216813
Bug ID: 216813
Summary: HFSC: "tc class change" can't remove rt service curve
Product: Networking
Version: 2.5
Kernel Version: 5.15.76
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
Assignee: stephen@networkplumber.org
Reporter: karel@unitednetworks.cz
Regression: No
When trying to change HFSC class with rt, ls and ul service curves "tc class
change" is unable to remove rt service curve.
System:
# uname -a
Linux karel2 5.15.76-gentoo #1 SMP PREEMPT Mon Oct 31 08:56:41 CET 2022 x86_64
AMD Ryzen 5 3600 6-Core Processor AuthenticAMD GNU/Linux
# tc -V
tc utility, iproute2-6.0.0
Let us create HFSC qdisc with one class having rt, ls, ul service curves:
# tc qdisc add dev lo root handle 1:0 hfsc
# tc class add dev lo parent 1:0 classid 1:1 hfsc ls m2 1Gbit ul m2 1Gbit
# tc class add dev lo parent 1:1 classid 1:2 hfsc rt m2 100Mbit ls m2 200Mbit
ul m2 300Mbit
# tc class show dev lo classid 1:2
class hfsc 1:2 parent 1:1 rt m1 0bit d 0us m2 100Mbit ls m1 0bit d 0us m2
200Mbit ul m1 0bit d 0us m2 300Mbit
```
Now when trying to remove rt from 1:2 class:
# tc class change dev lo parent 1:1 classid 1:2 hfsc rt m2 0kbit ls m2 201Mbit
ul m2 301Mbit
HFSC: Service Curve has two zero slopes
HFSC: Illegal "rt"
Ok, it doesn't accept empty service curve. Let us try to not specify rt:
# tc class change dev lo parent 1:1 classid 1:2 hfsc ls m2 202Mbit ul m2
302Mbit
# tc class show dev lo classid 1:2
class hfsc 1:2 parent 1:1 rt m1 0bit d 0us m2 100Mbit ls m1 0bit d 0us m2
202Mbit ul m1 0bit d 0us m2 302Mbit
Command is accepted but realtime service curve is still there. This is
apparently inconsistent behaviour. I would expect "tc class change" will remove
realtime curve if only link sharing and upper limit are passed.
If class has both rt and ls service curves, "tc class change" should be able to
remove one of them from class.
I would say there are two ways to achieve it:
1. allow to specify one of rt and ls to be "m2 0" and remove such curve from
class
2. respect passed parameters and when one of rt or ls is not specified, then
remove it from class if it is there
Second method seems to me more consistent.
I have looked at the source of iproute2 and check for two zero slopes is same
for adding and changing class:
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/tc/q_hfsc.c#n410
It would possible to rewrite this check to allow "tc class change" to pass one
of rt and ls with zero m2. But I am not sure if this is enough and what will
happen if two zero slopes are passed to HFSC.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
reply other threads:[~2022-12-16 17:24 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20221216092418.3e898d6f@hermes.local \
--to=stephen@networkplumber.org \
--cc=netdev@vger.kernel.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