Rare project developers

[Alexander Gall <>]

On Mon, 13 Jun 2022 11:45:27 +0200, mc36 <> said:

> 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

But how would you connect that port to the control-plane (assuming
that it's running on the same box)?

> setting an other front panel port a loopback and use that for 
> recirculation....

Yes, but hopefully we can avoid that.

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

True, but since the CPU port is harmless in the present case I'd like
to stay compatible with the default JSON file built into the model
binary (which uses port #2 as the CPU port for Tofino2).

In any case, we can keep RECIR_PORT constant with less drastic
measures for now.

-- 
Alex

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