Rare project developers

[Alexander Gall <>]

On Thu, 15 Dec 2022 17:29:25 +0100, Alexander Gall <> said:

> Hi Frédéric
> On Thu, 15 Dec 2022 17:14:59 +0100, Frédéric LOUI 
> <> said:

>> Hi,
>> Based on the ptf tests provided. INTEL concluded that this is more a 
>> global bug ( WRT TOFINO 1 & TOFINO 2) related to PHV allocation during p4c 
>> compilation.
>> This p4c « corner case » bug would most likely be visible on TOFINO 2. 
>> --dead-code-elimination is a trigger that would change PHV allocation and 
>> thus would more likely hide the bug instead of correcting it.

>>> If so, I will add the --no-dead-code-elimination flag to the build
>>> procedure for Tofino2-based platforms in the rare-nix repo.

>> IIUC, this can result in having a correct PHV allocation that would not 
>> yield the bug.
>> TBH this is not 100% sure that this PHV allocation would be correct for 
>> all RARE profile,

> I just tested this and it turns out that a lot of the profiles don't
> compile at all with --no-dead-code-elimination. The error always comes
> from the command assembler and complains about not having a PHV
> allocation for one or more fields in the ig_md. For example:

> /nix/store/kn8hd5c815j5md16zmydx9lwnn44ysvl-bf_router_VPLS-artifacts-2022.11.26/build/bf_router_VPLS/tofino2/pipe/bf_router.bfa:4395:
>  error: No phv record ig_md.bridge_trg
> failed command assembler

> That looks like another bug to me.

On second thought, maybe this means that without dead code
eliminination we simply run out of PHV space but the message is not
really clear to me :/ So this workaround (if it actually is one and
not another bug) seems no to be straight forward.

-- 
Alex

> So it seems there is no workaround
> for us :( I hope Intel has prioritized this issue and they will
> back-port it to the 9.7 LTS that we are still stuck with. I'll have to
> revisit the latter since APS now appears to support 9.11, but Netberg
> is still on 9.8 AFAICR and Inventec is kind of hopeless :(

> -- 
> Alex

>>> If so, I will add the --no-dead-code-elimination flag to the build
>>> procedure for Tofino2-based platforms in the rare-nix repo.

>> Yes for now, we have nothing better than adding «  
>> --no-dead-code-elimination » flag.
>> Good news is that we will be able to test all of them either with TNA2 
>> model but also we should have received 2xTOFINO2 switch in Geneva.

>>> My previous workaround (commit 09e14ee4 in the rare repo) only worked
>>> on the model but not on the ASIC. I notice that it has already been
>>> removed by the combination of commits 5b0e759 and 3d6d736. That's fine
>>> but I'm not sure if it was intentional (I'm still unhappy with these
>>> automated commits...).

>> MMhh … What you are mentioning is interesting. This would mean that PHV 
>> allocation has somewhat a runtime behaviour or is BSP related.

>> Anyway, more importantly, _WELCOME_BACK_ !

>> I’m on leave but feel free to move forward with your build. 
>> Xavier is eager to move forward with newest freeRtr (tna-experimental) 
>> release that would help debug LAG at the dataplane level.

>> All the best,
>> Frederic

>>> Le 15 déc. 2022 à 13:25, Alexander Gall <> a écrit :
>>> 
>>> Hi Frédéric
>>> 
>>> Thanks for helping to debug the issue with the dropped packets on
>>> Tofino2. Do I understand correctly that disabling dead-code
>>> eliminiation when compiling for Tofino2 is a workaround for this
>>> problem until Intel fixes the bug (P4C-5045) in the compiler?
>>> 
>>> If so, I will add the --no-dead-code-elimination flag to the build
>>> procedure for Tofino2-based platforms in the rare-nix repo.
>>> 
>>> My previous workaround (commit 09e14ee4 in the rare repo) only worked
>>> on the model but not on the ASIC. I notice that it has already been
>>> removed by the combination of commits 5b0e759 and 3d6d736. That's fine
>>> but I'm not sure if it was intentional (I'm still unhappy with these
>>> automated commits...).
>>> 
>>> -- 
>>> Alex