[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALnP8Za_MOB-m2u=jQe3_GZFhwJJSHZcL5A1P6iytxD+0hvvZA@mail.gmail.com>
Date: Mon, 5 Jun 2023 07:08:42 -0500
From: Marcelo Ricardo Leitner <mleitner@...hat.com>
To: Jamal Hadi Salim <jhs@...atatu.com>
Cc: netdev@...r.kernel.org, deb.chatterjee@...el.com, anjali.singhai@...el.com,
namrata.limaye@...el.com, tom@...anda.io, p4tc-discussions@...devconf.info,
Mahesh.Shirshyad@....com, Vipin.Jain@....com, tomasz.osinski@...el.com,
jiri@...nulli.us, xiyou.wangcong@...il.com, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, vladbu@...dia.com,
simon.horman@...igine.com, khalidm@...dia.com, toke@...hat.com
Subject: Re: [PATCH RFC v2 net-next 05/28] net/sched: act_api: introduce tc_lookup_action_byid()
On Sat, Jun 03, 2023 at 09:14:53AM -0400, Jamal Hadi Salim wrote:
> On Fri, Jun 2, 2023 at 3:36 PM Marcelo Ricardo Leitner
> <mleitner@...hat.com> wrote:
> >
> > On Wed, May 17, 2023 at 07:02:09AM -0400, Jamal Hadi Salim wrote:
> > > +/* lookup by ID */
> > > +struct tc_action_ops *tc_lookup_action_byid(struct net *net, u32 act_id)
> > > +{
> > > + struct tcf_dyn_act_net *base_net;
> > > + struct tc_action_ops *a, *res = NULL;
> > > +
> > > + if (!act_id)
> > > + return NULL;
> > > +
> > > + read_lock(&act_mod_lock);
> > > +
> > > + list_for_each_entry(a, &act_base, head) {
> > > + if (a->id == act_id) {
> > > + if (try_module_get(a->owner)) {
> > > + read_unlock(&act_mod_lock);
> > > + return a;
> > > + }
> > > + break;
> >
> > It shouldn't call break here but instead already return NULL:
> > if id matched, it cannot be present on the dyn list.
> >
> > Moreover, the search be optimized: now that TCA_ID_ is split between
> > fixed and dynamic ranges (patch #3), it could jump directly into the
> > right list. Control path performance is also important..
>
>
>
> Sorry - didnt respond to this last part: We could use standard tc
> actions in a P4 program and we prioritize looking at them first. This
> helper is currently only needed for us - so you could argue that we
> should only look TCA_ID_DYN onwards but it is useful to be more
> generic and since this is a slow path it is not critical. Unless i
Yes, and no. Control path is not as critical as datapath, I agree with
that, but it's also important. It's a small change, but oh well.. it
should accumulate on complex datapaths.
> misunderstood what you said.
I meant something like this:
+ if (act_id < TCA_ID_DYN) {
+ read_lock(&act_mod_lock);
+
+ list_for_each_entry(a, &act_base, head) {
+ if (a->id == act_id) {
+ if (try_module_get(a->owner)) {
+ read_unlock(&act_mod_lock);
+ return a;
+ }
+ break; /* now break; is okay */
+ }
+ }
+ read_unlock(&act_mod_lock);
+ } else {
+ read_lock(&base_net->act_mod_lock);
+
+ base_net = net_generic(net, dyn_act_net_id);
+ a = idr_find(&base_net->act_base, act_id);
+ if (a && try_module_get(a->owner))
+ res = a;
+
+ read_unlock(&base_net->act_mod_lock);
+ }
>
> cheers,
> jamal
>
> > > + }
> > > + }
> > > + read_unlock(&act_mod_lock);
> > > +
> > > + read_lock(&base_net->act_mod_lock);
> > > +
> > > + base_net = net_generic(net, dyn_act_net_id);
> > > + a = idr_find(&base_net->act_base, act_id);
> > > + if (a && try_module_get(a->owner))
> > > + res = a;
> > > +
> > > + read_unlock(&base_net->act_mod_lock);
> > > +
> > > + return res;
> > > +}
> > > +EXPORT_SYMBOL(tc_lookup_action_byid);
> >
>
Powered by blists - more mailing lists