Subject: Re: [p4tc-discussions] Re: [PATCH RFC v2 net-next 03/28] net/sched: act_api: increase TCA_ID_MAX

From: Jakub Kicinski <[email-masked]>
Date: Tue, 6 Jun 2023 10:15:29 -0700

On Tue, 6 Jun 2023 13:04:18 -0400 Jamal Hadi Salim wrote:
> > > diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
> > > index 5b66df3ec332..337411949ad0 100644
> > > --- a/include/uapi/linux/pkt_cls.h
> > > +++ b/include/uapi/linux/pkt_cls.h
> > > @@ -140,9 +140,9 @@ enum tca_id {
> > >       TCA_ID_MPLS,
> > >       TCA_ID_CT,
> > >       TCA_ID_GATE,
> > > -     TCA_ID_DYN,
> > > +     TCA_ID_DYN = 256,
> > >       /* other actions go here */
> > > -     __TCA_ID_MAX = 255
> > > +     __TCA_ID_MAX = 1023
> > >  };
> > >
> > >  #define TCA_ID_MAX __TCA_ID_MAX  
> >
> > I haven't look at any of the patches but this stands out as bad idea
> > on the surface.  
> 
> The idea is to reserve a range of the IDs for dynamic use in this case
> from 256-1023. The kernel will issue an action id from that range when
> we request it. The assumption is someone adding a "static" action ID
> will populate the above enum and is able to move the range boundaries.
> P4TC continues to work with old and new kernels and with old and new
> tc.
> Did i miss something you were alluding to?

Allocating action IDs for P4 at the same level as normal TC actions
makes the P4 stuff looks like a total parallel implementation to me.
Why is there not a TCA_ID_P4 which muxes internally?
AFAIU interpretation of action attributes depends on the ID, which
means that user space to parse the action attrs has to not only look 
at the ID but now also resolve what that ID means.