Rare project developers

[mc36 <>]

during testing this, i noticed the following on my model vm:

root@rare:~# release-manager --switch-to-generation 1
/nix/var/nix/profiles/RARE/bin/release-manager: line 217: syntax error in 
conditional expression
Unexpected error, aborting
root@rare:~#

br,
cs


On 6/13/22 14:25, mc36 wrote:
> here we goo:
> https://bitbucket.software.geant.org/projects/RARE/repos/rare/commits/e1122d42f31af01148f364ae9121e9cbd4c36fff
> br
> ,cs
>
>
> On 6/13/22 11:45, mc36 wrote:
> > hi,
> > omfg... okk, i'll add your 1% fallback suggestion then, instead of 
> > reoptimizing...
> > regarding the cpu/recir port on the model or even on a real tofino, imho we 
> > can use
> > anything as long as both the surrounding hardware and the tofino.bin have a 
> > consensus...
> > i mean, in case of a real chip, so we mostly better off with the built ins, 
> > but,
> > nobody can stop us using a front panel port as a cpuport, and setting an other
> > front panel port a loopback and use that for recirculation....
> > (i found a bier poc flying around for tofino doing the latter)
> > regarding the model, it's even easier than the above, since you can define 
> > anything
> > to anywhere in the port.json...
> > br,
> > cs
> >
> >
> > On 6/13/22 10:33, Alexander Gall wrote:
> > > On Fri, 10 Jun 2022 07:26:36 +0200, mc36 <> said:
> > >
> > > > On 6/10/22 06:53, mc36 wrote:
> > > > > wait a bit... adding that multi-options stuff is no matter of time to have...
> > > > > and we still can decide to just use a single set of them....
> > > > https://bitbucket.software.geant.org/projects/RARE/repos/rare/commits/484fea3b8de9fc091a6a2a2d835924089b48f5ee
> > > > here we goo... i updated r.sh and rp.sh according to the new parameters... 
> > > > also added optimizer1.txt and
> > > > optimizer2.txt for tofino1 and tofino2 use case...
> > >
> > > Things are getting even stranger. However, we don't have to deal with
> > > the worst of it, at least not for now. The source of the problem is
> > > that with our current P4 code, optimizations for different values of
> > > RECIR_PORT on Tofino2 can differ significantly (I give an example of a
> > > really nasty case below).
> > >
> > > We don't understand why this is so, but luckily we only need one
> > > specific value for RECIR_PORT for Tofino2 and thus we can simply
> > > ignore it.   In fact, we only need two variants of the Tofino2 code if
> > > we want to include support for the Tofino2 model in RARE and a single
> > > variant if we don't:
> > >
> > > ASIC:
> > >      CPU_PORT: 0
> > >      RECIT_PORT: 1
> > >
> > > Tofino2 model:
> > >      CPU_PORT: 2
> > >      RECIR_PORT: 1
> > >
> > > Just as the Tofino model, the Tofino2 model doesn't emulate the CPU
> > > PCIe port but uses the lowest of the CPU Eth ports (i.e. port #2 for
> > > Tofino2 and port #64 for Tofino1).
> > >
> > > I have commited these assignments and the Tofino2 optimization for
> > > 9.7.2 and all looks good.
> > >
> > > Now for the nasty details. First of all, the Tofino2 compiler seems to
> > > be extremely sensitive to even the slightes changes in the code. For
> > > example, your commit
> > > https://bitbucket.software.geant.org/projects/RARE/repos/rare/commits/233cce079794dc91afc5c4d9071fa5ea756f2b65
> > > caused some of the profiles to fail compilation with the optimization
> > > from
> > > https://bitbucket.software.geant.org/projects/RARE/repos/rare/commits/ceda33ac1784d4350ecd417b05a0d864bd45a9fc
> > >
> > > This is something to look out for when we push changes in the future
> > > (i.e. that could result in non-compilable code until the optimizer is
> > > run again.
> > >
> > > But now to the really bad stuff. Before I committed the changes for
> > > the Tofino2 model, the compilations with and without
> > > -D{DUAL,QUAD}_PIPE differed in the value of RECIR_PORT. I used these
> > > two configurations
> > >
> > > -b tofino2 -a t2na
> > > -b tofino2 -a t2na -DQUAD_PIPE
> > >
> > > with the GRE profile. The first config optimizes to the values 401408
> > > and 45056. The second config fails to compile with that, so the
> > > optimizer is run again and results in the values 401408, 43520.
> > >
> > > Now comes the kicker: the first config does *not* compile with these
> > > lower values! I found that reducing 40140 and 43520 by 5% results in
> > > successful compilation of both configurations. So, a better strategy
> > > than running a full optimization on the second config might be to
> > > reduce the first set of numbers step by step by, say, 1% until all
> > > configurations compile successfully, assuming that the difference
> > > won't be huge.
> > >
> > > But, as I said, we don't have to deal with that (yet).