[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_iQpVVJ=8dSj7pGo+68wG5zfMop_weUh_N9EX0kO5P11NQJw@mail.gmail.com>
Date: Sun, 11 Jan 2026 12:39:21 -0800
From: Cong Wang <xiyou.wangcong@...il.com>
To: Jamal Hadi Salim <jhs@...atatu.com>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, horms@...nel.org, andrew+netdev@...n.ch,
netdev@...r.kernel.org, jiri@...nulli.us, victor@...atatu.com,
dcaratti@...hat.com, lariel@...dia.com, daniel@...earbox.net,
pablo@...filter.org, kadlec@...filter.org, fw@...len.de, phil@....cc,
netfilter-devel@...r.kernel.org, coreteam@...filter.org,
zyc199902@...omail.cn, lrGerlinde@...lfence.com, jschung2@...ton.me,
William Liu <will@...lsroot.io>, Savino Dicanosa <savy@...t3mfailure.io>
Subject: Re: [PATCH net 5/6] net/sched: fix packet loop on netem when
duplicate is on
On Sun, Jan 11, 2026 at 8:40 AM Jamal Hadi Salim <jhs@...atatu.com> wrote:
> - q->duplicate = 0;
> + skb2->ttl++; /* prevent duplicating a dup... */
> rootq->enqueue(skb2, rootq, to_free);
> - q->duplicate = dupsave;
As I already explained many times, the ROOT cause is enqueuing
to the root qdisc, not anything else.
We need to completely forget all the kernel knowledge and ask
a very simple question here: is enqueuing to root qdisc a reasonable
use? More importantly, could we really define it?
I already provided my answer in my patch description, sorry for not
keeping repeating it for at least the 3rd time.
Therefore, I still don't think you fix the root cause here. The
problematic behavior of enqueuing to root qdisc should be corrected,
regardless of any kernel detail.
Thanks.
Cong
Powered by blists - more mailing lists