Rare project developers

[mc36 <>]

hi,
hmmm..... sounds weirdo.... but what if we work around this somehow?
i'm thinking about making the optimizer to deal with multiple options in a 
final+1 round,
where you could list some additional compiler options....
so let's say, from now, you'll have to provide a new file that lists the 
default options
in the first line, but every additional live you could list additional set of 
options to
try with, and if any of those fails, then i'll try to decrease the table 
sizes?
thanks,
cs

On 6/9/22 16:57, Alexander Gall wrote:
> On Thu, 9 Jun 2022 08:10:44 +0200, mc36 <> said:
>
> > hi,
> > okay then, as we never seen such before, then lemme revert back to even 
> > numbers....
> > https://bitbucket.software.geant.org/projects/RARE/repos/rare/commits/865cbb37cf80f38fc142c8af44a20a57a4ea1c4b
>
> This is getting really weird. I re-optimized with this change and it
> happened again. Well, not exactly, but I can't really reconstruct what
> really happened the first time.
>
> What I have now is amazing. I have the GRE profile optimized
> successfully to this (with 9.7.2):
>
> #ifdef PROFILE_GRE
> #define HAVE_ALPM
> #define HAVE_GRE
> #define HAVE_TUN
>
> #define PORT_TABLE_SIZE                45056
> #define BUNDLE_TABLE_SIZE                      128
> #define VLAN_TABLE_SIZE                        512
> #define IPV4_LPM_TABLE_SIZE            401408
> #define IPV6_LPM_TABLE_SIZE            100352
> #define IPV4_HOST_TABLE_SIZE                   256
> #define IPV6_HOST_TABLE_SIZE                   256
> #define NEXTHOP_TABLE_SIZE             45056
> #define IPV4_TUNNEL_TABLE_SIZE         45056
> #define IPV6_TUNNEL_TABLE_SIZE         22528
> #define _TABLE_SIZE_P4_
> #endif
>
> When I compile just with -DPROFILE_GRE (what the optimizer does), it
> works. But when I compile with either -DDUAL_PIPE or -DQUAD_PIPE, I
> get
>
> bf_router.tofino2/pipe/bf_router.bfa:5717: error: tofino2 supports up to 20 
> stages, using 21
> bf_router.tofino2/pipe/bf_router.bfa:0: error: Due to errors, no binary will 
> be generated
> failed command assembler
>
> But these defines simply change the values of CPU_PORT and
> RECIR_PORT. It turns out that setting RECIR_PORT to 1 leads to this
> failure. The compiler also takes significantly longer to get there as
> when the compilation is successful.
>
> I don't know how to deal with this yet. It's probably not a bug but a
> very extreme outcome of optimizing the MAU resources.