Rare project developers

[mc36 <>]

hi,
so for tofino we have an alias to populate the front panel ports, and it 
fills the description with the port/channel info too...
for the rest of the dataplanes, i like that i can change the dataplanes 
without changing the p4lang config stanza at all...
so to sum it up, i personally also on the opinion to keep the current method, 
that is, the numbers....
regards,
cs

On 2/21/22 18:12, Frederic LOUI wrote:
>    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.
>      >