RARE user and assistance email list

[Alexander Gall <>]

On Wed, 10 Jan 2024 10:53:50 +0100, mc36 <> said:

> so i had no packets at all on the regular 192 cpu port at all,

> nor ingress nor egress, to/from the x86 board toward the frontpanel ports...

It certainly isn't a fundamental problem with that platform since both
of our systems are happily passing packets through that port, e.g.

root@gva0081-mbc:~# ifconfig bf_pci0
bf_pci0: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 9710
        inet6 fe80::202:ff:fe00:300  prefixlen 64  scopeid 0x20<link>
        ether 00:02:00:00:03:00  txqueuelen 1000  (Ethernet)
        RX packets 715653  bytes 99202821 (94.6 MiB)
        RX errors 0  dropped 10818  overruns 0  frame 0
        TX packets 1176937  bytes 157571382 (150.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I can't tell you what's the problem with your system but I'm pretty
sure it's not a hardware issue. Did you use our ONIE installer or some
other method to set it up?

> then in the documentation its clearly stated that the x86 control board on

> this model wired to the tofino port 66, so that's the reason...

Sure, ports 66 and 67 (33/2 and 33/3) are the "CPU Eth" ports on this
platform. The problem with that approach is that it is
platform-dependent (on the Wedge 32X, for example, it's ports 64 and
66). It requires to compile the P4 program specifically for that
platform and, as you say below, also needs changes to the forwarder
(presumably to bring port 33/2 up?). That is very annoying.

OTOH, the PCIe CPU port is present on all platform as part of the PCI
interface to the ASIC.

So I strongly suggest to figure what what's wrong on your system
instead of implementing these platform-specific changes.

-- 
Alex

> ohh yeahhh and an other catch, that is not _yet_ pushed back, is that this

> port needs to be set up by the bffwd.py by bfrt calls to operate...

> (for this latter i've opened a ticket at their github so im waiting a

> bit before giving up on this and pushing out the related 3 lines)

> br,

> cs





> On 1/10/24 08:52, Alexander Gall wrote:
>> 
>> Hi Csaba
>> 
>> Happy New Year :)
>> 
>> I hear that you have a problem with the CPU PCIe port on the X312P. I
>> see in the diffs that you use one of the CPU Eth ports (port 66)
>> instead:
>> 
>> diff -Naur /home/gall/rare/p4src/include/cst_cpu_port.p4 
>> p4bf/include/cst_cpu_port.p4
>> --- /home/gall/rare/p4src/include/cst_cpu_port.p4       2023-01-16 
>> 09:49:45.060475967 +0100
>> +++ p4bf/include/cst_cpu_port.p4        2024-01-10 08:18:44.105125032 +0100
>> @@ -52,7 +52,12 @@
>> 
>> */
>> 
>> -#if defined DUAL_PIPE || defined _WEDGE100BF32X_
>> +#if defined _ASTERFUSIONx312p_
>> +
>> +#define CPU_PORT 66
>> +#define RECIR_PORT 68
>> +
>> +#elif defined DUAL_PIPE || defined _WEDGE100BF32X_
>> 
>> #if __TARGET_TOFINO__ == 2
>> 
>> 
>> What exactly is the problem with the regular CPU PCIe port 192? The
>> X312P is a regular 2-pipe Tofino and works fine with port 192 on the
>> two boxes in the P4 lab. As usual, the port is represented on the
>> Linux side as device bf_pci0 (or some other name if you don't use the
>> udev setup from our ONIE installer) provided by the bf_kpkt kernel
>> module.
>> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#2268): https://groups.io/g/freertr/message/2268
Mute This Topic: https://groups.io/mt/103638116/6413194
Group Owner: 
Unsubscribe: https://groups.io/g/freertr/unsub []
-=-=-=-=-=-=-=-=-=-=-=-