Rare project developers

[mc36 <>]

hi,
taking a closer look on what's going on, i just realized that this pre_emit 
stuff is basically just before the very core tocpu check:
https://github.com/rare-freertr/freeRtr/blob/7a417d4537db9cbae8fdcb9f618ef008f62f3913/misc/p4bf/include/ig_ctl.p4#L187
so for now, i strongly believe that we can get rid of all the ternary matches 
here if we split the table... the cpuhdr
insertion could go directly to the inner part of the if, and the rest could 
go to the else part... for the bridging ternary,
i can easily list all the possible values for the sap_en/de_cap so this table 
could easily become an all-exact.... let's see.... :)
br,
cs


On 6/2/22 11:02, mc36 wrote:
> hi,
> thanks for playing with it and finding a workaround...
> that field is not exactly ternary, it was just written this way to shrink 
> that table...
> so the values are very well defined and could be listed explicitly... imho 
> i'll do that,
> i'll validate on the test cases and then we can replace ternary to exact for 
> that field...
> br,
> cs
>
>
>
> On 6/2/22 10:27, Alexander Gall wrote:
> > Interesting. The problem goes away when I add a redundant entry with a
> > fixed value of mpls_encap_decap_sap_type in the global part of
> > include/ig_ctl_pkt_pre_emit.p4:
> >
> > diff --git a/p4src/include/ig_ctl_pkt_pre_emit.p4
> > b/p4src/include/ig_ctl_pkt_pre_emit.p4
> > index c53597f..0575f34 100644
> > --- a/p4src/include/ig_ctl_pkt_pre_emit.p4
> > +++ b/p4src/include/ig_ctl_pkt_pre_emit.p4
> > @@ -309,6 +309,7 @@ ig_md.nexthop_id:
> >                            (1, 0, 0, 0, 0, 0, 0, 0, 4, 
> > _):act_pkt_srv_l3vpn_ipv4_encap();
> >                            (1, 0, 0, 0, 0, 0, 0, 0, 6, 
> > _):act_pkt_srv_l3vpn_ipv6_encap();
> >    #endif
> > +                       (0, 0, 0, 0, 0, 0, 0, 0, 4, 
> > CPU_PORT):act_pkt_send_to_cpu();
> >                            (0, 0, 0, 0, 0, 0, 0, 0, _, 
> > CPU_PORT):act_pkt_send_to_cpu();
> >                            (0, 0, 0, 0, 0, 0, 0, 1, _, 
> > CPU_PORT):act_pkt_send_to_cpu();
> >                            (0, 0, 0, 0, 0, 0, 1, 0, _, 
> > CPU_PORT):act_pkt_send_to_cpu();
> >
> > That seems like an easy workaround :)