From: Cong Wang <xiyou.wangcong@gmail.com>
To: William Liu <will@willsroot.io>
Cc: netdev@vger.kernel.org, jhs@mojatatu.com,
stephen@networkplumber.org,
Savino Dicanosa <savy@syst3mfailure.io>
Subject: Re: [Patch v3 net 1/4] net_sched: Implement the right netem duplication behavior
Date: Tue, 15 Jul 2025 11:03:30 -0700 [thread overview]
Message-ID: <aHaX8n8o/fLBi57L@pop-os.localdomain> (raw)
In-Reply-To: <pGE9OHWRSf4oJwC4gS0oPonBy8_0WsDthxgLzBYGBtMVeT_EDc-HAz8NbhJxcWe0NEUrf_a7Fyq2op5FVFujfc2KyO-I38Yx_HlQhFwB0Cs=@willsroot.io>
On Mon, Jul 14, 2025 at 02:30:26AM +0000, William Liu wrote:
> FWIW, I suggested changing this behavior to not enqueue from the root a while ago too on the security mailing list for the HFSC rsc bug (as the re-entrancy violated assumptions in other qdiscs), but was told some users might be expecting that behavior and we would break their setups.
Thanks for your valuable input.
Instead of arguing on what users expect, I think it is fair to use the
man page as our argreement with user. Please let me know if you have
more reasonable argreement or more reasonable use case for us to justify
updates to the man page.
I have an open mind.
>
> If we really want to preserve the ability to have multiple duplicating netems in a tree, I think Jamal had a good suggestion here to rely on tc_skb_ext extensions [1].
Do you mind to be more specific here? I don't think I am following you
on why tc_skb_ext is better here.
The reason why I changed back to netem_skb_cb is exactly because of the
enqueue beahvior change, which now only allows the skb to be queued to
the same qdisc.
If you have a specific reasonable use case you suspect my patch might
break, please share it with me. It would help me to understand you
better and more importantly to test this patch more comprehensively,
I'd love to add as many selftests as I can.
>
> However, I noted that there are implementation issues that we would have to deal with. Copying what I said there [2]:
>
> "The tc_skb_ext approach has a problem... the config option that enables it is NET_TC_SKB_EXT. I assumed this is a generic name for skb extensions in the tc subsystem, but unfortunately this is hardcoded for NET_CLS_ACT recirculation support.
IMHO, Kconfig is not a problem here, we just need to deal with the
necessary dependency if we really need to use it.
Like I said above, I don't see the problem of using netem_skb_cb after
enqueuing to the same qdisc, this is the only reason why I don't see the
need to changing it to either tc_skb_cb or skb_ext.
Thanks for your review!
next prev parent reply other threads:[~2025-07-15 18:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-13 21:47 [Patch v3 net 0/4] netem: Fix skb duplication logic and prevent infinite loops Cong Wang
2025-07-13 21:47 ` [Patch v3 net 1/4] net_sched: Implement the right netem duplication behavior Cong Wang
2025-07-13 22:01 ` Cong Wang
2025-07-13 22:12 ` Stephen Hemminger
2025-07-15 17:48 ` Cong Wang
2025-07-14 2:30 ` William Liu
2025-07-15 18:03 ` Cong Wang [this message]
2025-07-15 18:41 ` William Liu
2025-07-13 21:47 ` [Patch v3 net 2/4] selftests/tc-testing: Add a nested netem duplicate test Cong Wang
2025-07-13 21:47 ` [Patch v3 net 3/4] selftests/tc-testing: Add a test case for piro with netem duplicate Cong Wang
2025-07-13 21:47 ` [Patch v3 net 4/4] selftests/tc-testing: Add a test case for mq " Cong Wang
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=aHaX8n8o/fLBi57L@pop-os.localdomain \
--to=xiyou.wangcong@gmail.com \
--cc=jhs@mojatatu.com \
--cc=netdev@vger.kernel.org \
--cc=savy@syst3mfailure.io \
--cc=stephen@networkplumber.org \
--cc=will@willsroot.io \
/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