Rare project developers

[Frederic LOUI <>]

 Or sure if it helps, but i can give you this:

TOFINO_ID <---> FP_ID and give you the hw_id range.

For example [0-200] for wedge 32x for wedge 64 the range will be different obviously. And sometimes port I'd allocation differ from one wedge and the others.

For virtual construct Tunnel/Virtual Access freertr can use any value that is not in range below? One virtual construct can get an id from a function that return first available I'd within a range external to [0-200]

To be honest, I'm personally fine with the behavior as it is now. Granted the fact that this needs to be documented.but i can understand that one has difficulty to grasp this I'd allocation (and sometimes without docs)

I can then send you a port_id message 

<port_id tofino_id fp_id>

please let me know your thoughts.

For DPDK it is even more tricky ... Use of pcie_id ?

For p4emu use of systems id ?

Your opinion ?

Le 21 févr. 2022 17:57, mc36 <> a écrit :

hi,
this question falls from the trivial:
right now, bffwd, as name suggests, only forwards messages from text to grpc...
this is a one-way communication... the only reverse path is counter reporting...
and this id appears on packets from cpuport's first 16 bits, this is how the
dataplane signals that which port got the packet that is decided for upper processing...
(on the cpuport, the reverse path also have this id to signal where the packet need to be sent...)
and this id is clearly not a single point of assignment because there are virtual
constructs like subinterface, dialer, virtualppp, pwether, bvi, tunnel and friends
which are clearly not in the dataplane, moreover we have dynamically created virtual-access
interfaces from pppoe, l2tp, vpls, evpn and friends... and tofino is not the only one,
on ebpf and dpdk we use the kernel's/dpdk's assigned handle...

to have a string at that location, i only see the following idea:
the dataplanes could report the id to string mapping during startup
then freerouter can store it and translate internally...
but then one still have to deal with the virtual constructs and assign them a usable id...
(in case of tofino, one that is cannot never ever be a physical port id to steal the traffic...)
regards,
cs


On 2/21/22 17:11, Alexander Gall wrote:
> Hi csaba, Frederic
>
> The current discion on the "Basic Bridge" on RARE-usres has reminded
> me of a feature that we should implement to increase the user
> experience.
>
> Currently, one has to specify the physical port ID in the
> "export-port" statement, which is a major problem for people who are
> not really familiar with Tofino inernals. IMHO, there is no reason at
> all to use the physical port there. Why not simply use the much
> friendlier "port/channel" (e.g. "1/0") identifier to directly address
> the ports on the device's front panel?  bf_forwarder can easily
> translate that into the physical port ID by a lookup in the
> $PORT_STR_INFO table.
>
> This would require to change the parser in freerouter as well as the
> format of the message passed to bf_forwarder.
>