From: Vladimir Oltean <olteanv@gmail.com>
To: Ido Schimmel <idosch@idosch.org>
Cc: Jianbo Liu <jianbol@nvidia.com>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, andrew@lunn.ch,
vivien.didelot@gmail.com, f.fainelli@gmail.com,
davem@davemloft.net, kuba@kernel.org, rajur@chelsio.com,
claudiu.manoil@nxp.com, sgoutham@marvell.com, gakula@marvell.com,
sbhatta@marvell.com, hkelam@marvell.com, saeedm@nvidia.com,
leon@kernel.org, idosch@nvidia.com, petrm@nvidia.com,
alexandre.belloni@bootlin.com, UNGLinuxDriver@microchip.com,
simon.horman@corigine.com, jhs@mojatatu.com,
xiyou.wangcong@gmail.com, jiri@resnulli.us,
baowen.zheng@corigine.com, louis.peens@netronome.com,
peng.zhang@corigine.com, oss-drivers@corigine.com,
roid@nvidia.com
Subject: Re: [PATCH net-next v3 1/2] net: flow_offload: add tc police action parameters
Date: Thu, 17 Mar 2022 20:52:49 +0200 [thread overview]
Message-ID: <20220317185249.5mff5u2x624pjewv@skbuf> (raw)
In-Reply-To: <YjM2IhX4k5XHnya0@shredder>
On Thu, Mar 17, 2022 at 03:22:42PM +0200, Ido Schimmel wrote:
> > I don't know why just now, but I observed an apparent regression here
> > with these commands:
> >
> > root@debian:~# tc qdisc add dev swp3 clsact
> > root@debian:~# tc filter add dev swp3 ingress protocol ip flower skip_sw ip_proto icmp action police rate 100Mbit burst 10000
> > [ 45.767900] tcf_police_act_to_flow_act: 434: tc_act 1
> > [ 45.773100] tcf_police_offload_act_setup: 475, act_id -95
> > Error: cls_flower: Failed to setup flow action.
> > We have an error talking to the kernel, -1
> >
> > The reason why I'm not sure is because I don't know if this should have
> > worked as intended or not. I am remarking just now in "man tc-police"
> > that the default conform-exceed action is "reclassify".
> >
> > So if I specify "conform-exceed drop", things are as expected, but with
> > the default (implicitly "conform-exceed reclassify") things fail with
> > -EOPNOTSUPP because tcf_police_act_to_flow_act() doesn't handle a
> > police->tcf_action of TC_ACT_RECLASSIFY.
> >
> > Should it?
>
> Even if tcf_police_act_to_flow_act() handled "reclassify", the
> configuration would have been rejected later on by the relevant device
> driver since they all support "drop" for exceed action and nothing else.
This is correct, but currently, the error is:
Error: cls_flower: Failed to setup flow action.
We have an error talking to the kernel, -1
I'd appreciate if the error was instead:
Error: mscc_ocelot: Offload not supported when exceed action is not drop.
which is basically what Jianbo was trying to achieve when he added the
policer_validate() functions. At least I'd know what's wrong. No?
> I don't know why iproute2 defaults to "reclassify", but the
> configuration in the example does something different in the SW and HW
> data paths. One ugly suggestion to keep this case working it to have
> tcf_police_act_to_flow_act() default to "drop" and emit a warning via
> extack so that user space is at least aware of this misconfiguration.
I don't want to force a reinterpretation of "reclassify" just to make
something that used to work by mistake continue to work. It sucks to
have to adapt, but not being able to make progress because of such
things sucks even more.
I'd just like the 'reclassify' action to be propagated in some reasonable
way to flow offload, considering that at the moment the error is quite cryptic.
> > > + if (act_id < 0)
> > > + return act_id;
> > > +
> > > + entry->police.exceed.act_id = act_id;
> > > +
> > > + act_id = tcf_police_act_to_flow_act(p->tcfp_result,
> > > + &entry->police.notexceed.extval);
> > > + if (act_id < 0)
> > > + return act_id;
> > > +
> > > + entry->police.notexceed.act_id = act_id;
> > > +
> > > *index_inc = 1;
> > > } else {
> > > struct flow_offload_action *fl_action = entry_data;
> > > --
> > > 2.26.2
> > >
next prev parent reply other threads:[~2022-03-17 18:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-24 10:29 [PATCH net-next v3 0/2] flow_offload: add tc police parameters Jianbo Liu
2022-02-24 10:29 ` [PATCH net-next v3 1/2] net: flow_offload: add tc police action parameters Jianbo Liu
2022-03-15 19:13 ` Vladimir Oltean
2022-03-17 13:22 ` Ido Schimmel
2022-03-17 18:52 ` Vladimir Oltean [this message]
2022-03-17 19:37 ` Ido Schimmel
2022-03-22 10:13 ` Ido Schimmel
2022-04-06 14:30 ` Vladimir Oltean
2022-02-24 10:29 ` [PATCH net-next v3 2/2] flow_offload: reject offload for all drivers with invalid police parameters Jianbo Liu
2022-02-28 11:40 ` [PATCH net-next v3 0/2] flow_offload: add tc " patchwork-bot+netdevbpf
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=20220317185249.5mff5u2x624pjewv@skbuf \
--to=olteanv@gmail.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=alexandre.belloni@bootlin.com \
--cc=andrew@lunn.ch \
--cc=baowen.zheng@corigine.com \
--cc=claudiu.manoil@nxp.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=gakula@marvell.com \
--cc=hkelam@marvell.com \
--cc=idosch@idosch.org \
--cc=idosch@nvidia.com \
--cc=jhs@mojatatu.com \
--cc=jianbol@nvidia.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=louis.peens@netronome.com \
--cc=netdev@vger.kernel.org \
--cc=oss-drivers@corigine.com \
--cc=peng.zhang@corigine.com \
--cc=petrm@nvidia.com \
--cc=rajur@chelsio.com \
--cc=roid@nvidia.com \
--cc=saeedm@nvidia.com \
--cc=sbhatta@marvell.com \
--cc=sgoutham@marvell.com \
--cc=simon.horman@corigine.com \
--cc=vivien.didelot@gmail.com \
--cc=xiyou.wangcong@gmail.com \
/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