[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAM0EoMkqijrTv7SSrQf2sHEZWShgfwLKzcVtPT17HK3vR-gsrA@mail.gmail.com>
Date: Mon, 25 Dec 2023 18:01:15 -0500
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Stephen Hemminger <stephen@...workplumber.org>
Cc: Florian Westphal <fw@...len.de>, Jamal Hadi Salim <hadi@...atatu.com>, netdev@...r.kernel.org
Subject: Re: [RFC iproute2-next] remove support for iptables action
On Sun, Dec 24, 2023 at 12:11 PM Stephen Hemminger
<stephen@...workplumber.org> wrote:
>
> On Sat, 23 Dec 2023 13:31:03 +0100
> Florian Westphal <fw@...len.de> wrote:
>
> > Stephen Hemminger <stephen@...workplumber.org> wrote:
> > > tc/em_ipset.c | 260 --------------
> >
> > Not sure if this is unused, also not related to the iptables/xt action.
>
> There is both the xtables and ematch options to TC.
> Jamal do you want to remove both, or some subset?
>
just the m_ipt/xt (not the em_xxx) which maps to the kernel ipt action
(not the em_ipt which is part of a much larger combination of
matchers, do "ls net/sched/em*.c", of which matching on ipt is one
small part).
There are people still using ematch... (as Eyal just posted to).
> The problematic area for iproute2 seems to be the dependency on libiptables
> which is not very stable. On the kernel side it is one of the places
> where lightly tested integration could lead to lots of syszbot errors.
Note: the motivation for removing act_ipt was not syszbot, rather it
being overtaken by events. AFAIK, there's never been a syszbot issue
with either act_ipt or the ematcher.
I do empathize with your comment on the challenges on the library.
cheers,
jamal
Powered by blists - more mailing lists