Rare project developers

[Alexander Gall <>]

Hi

On Thu, 9 Jun 2022 17:06:56 +0200, mc36 <> said:

> 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?

Actually, it seems that we could simply use one of the options (they
both do the exact same thing) for all rounds when optimizing for
Tofino2, since this is how the actual profiles are being compiled
during packaging.

We should be using the same flags for optimization and building in
general. The packaging has provisions to have per-profile flags, but
currently only --disable-parse-depth-limit is used selectively for a
few profiles, but that can also be applied in general (for Tofino1)
without impacting the resource allocation. It would make sense to have
the optimizer access the flags from the Nix expression for the RARE
package to make sure there will be no surprises in the future.

I'll think about that later. Right now the situation is still simple
and I'll just re-run the optimizer with "-DQUAD_PIPE" today (maybe
that's also what I did the other day, I don't remember).

-- 
Alex

> 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.
>>