[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM0EoM=VHt3VakG6n81Lt+6LFzOVKAL-uzjM2y_xuWMv5kE+JA@mail.gmail.com>
Date: Wed, 14 Jan 2026 11:33:55 -0500
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Cong Wang <xiyou.wangcong@...il.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>, Savy <savy@...t3mfailure.io>
Subject: Re: [PATCH net 0/6] net/sched: Fix packet loops in mirred and netem
On Tue, Jan 13, 2026 at 3:10 PM Cong Wang <xiyou.wangcong@...il.com> wrote:
>
> On Sun, Jan 11, 2026 at 8:40 AM Jamal Hadi Salim <jhs@...atatu.com> wrote:
> >
> >
> > We introduce a 2-bit global skb->ttl counter.Patch #1 describes how we puti
> > together those bits. Patches #2 and patch #5 use these bits.
> > I added Fixes tags to patch #1 in case it is useful for backporting.
> > Patch #3 and #4 revert William's earlier netem commits. Patch #6 introduces
> > tdc test cases.
>
> 3 reasons why this patchset should be rejected:
>
> 1) It increases sk_buff size potentially by 1 byte with minimal config
>
All distro vendors turn all options. So no change in size happens.
Regardless, it's a non-arguement there is no way to resolve the mirred
issue without global state.
It's a twofer - fixing mirred and netem.
> 2) Infinite loop is the symptom caused by enqueuing to the root qdisc,
> fixing the infinite loop itself is fixing the symptom and covering up the
> root cause deeper.
>
The behavior of sending to the root has been around for ~20 years.
I just saw your patches - do you mind explaining why you didnt Cc me on them?
> 3) Using skb->ttl makes netem duplication behavior less predictable
> for users. With a TTL-based approach, the duplication depth is limited
> by a kernel-internal constant that is invisible to userspace. Users
> configuring nested netem hierarchies cannot determine from tc
> commands alone whether their packets will be duplicated at each
> stage or silently pass through when TTL is exhausted.
>
The patch is not using the ttl as a counter for netem, it's being
treated as boolean (just like your patch is doing). We are only using
this as a counter for the mirred loop use case.
> NACKed-by: Cong Wang <xiyou.wangcong@...il.com>
Calm down please.
cheers
jamal
Powered by blists - more mailing lists