Message-ID: <ab86a457-aab0-1ea3-3161-2630491585d7@moenia.de>
Date: Sat, 9 Aug 2025 22:03:10 +0200
From: lkml-xx-15438@...werbittewas.de
To: netdev@...r.kernel.org
Subject: problems with hfsc since 5.10.238-patches in sched_hfsc.c

hi.

hopefully the right list for this problem, else please tell me the right
one.

Problem:
after updating to 5.10.238 (manually compiled) hfsc is malfunctioning here.
after a long time with noch changes and no problems, most packages are
dropped without notice.

after some tries we've identified the patches

- https://lore.kernel.org/all/20250425220710.3964791-3-victor@mojatatu.com/

and

-
https://lore.kernel.org/all/20250522181448.1439717-2-pctammela@mojatatu.com/

which seems to lead to misbehaviour.


by changing the line in hfsc_enqueue()

"if (first && !cl_in_el_or_vttree(cl)) {"

back to

"if (first) {"

all went well again.


if it matters: we're using a simple net-ns-container for
forwarding/scheduling the local dsl-line


maybe we're using a config of hfsc, which is not ok (but we're doing
this over several years)

our hfsc-init is like:


/sbin/tc qdisc add dev eth0 root handle 1: hfsc default 14

/sbin/tc class add dev eth0 parent 1: classid 1:10 hfsc ls m2 36000kbit
ul m2 36000kbit

/sbin/tc class add dev eth0 parent 1:10 classid 1:14 hfsc ls m1
36000kbit d 10000ms m2 30000kbit ul m1 30000kbit d 10000ms m2 25000kbit

(normally there are further lines, but above calls are sufficant to
either forward the packets before .238 or let them drop with .238 or
later. we're using an old tc (iproute2-5.11.0) on this system.


so, it would be nice, if someone can tell us, why the above
hfsc-init-calls are bad, or if they're ok and the changes in 5.10.238
have side-effects, which lead to this behaviour.


thanks a lot.

regards

x.

Powered by blists - more mailing lists