Rare project developers

[Alexander Gall <>]

Hi

On Mon, 21 Feb 2022 17:57:12 +0100, mc36 <> said:

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

Ok, so it's not entirely trivial :)  Maybe we can't avoid that the
user needs to deal with data-plane-dependent identifiers completely,
but I think we should try to avoid it as much as possible.

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

Yes, I think we should do that.

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

And that's exactly the kind of problem we should try to avoid
IMHO. Let's look at sub-interfaces, for example:

interface sdn1
interface sdn1.99

server p4lang p4
  export-port sdn1 128 100 0 0 0
  export-port sdn1.99 200 0 0 0 0

This generates two different messages to the forwarder. The first one

"state 128 100 0 0 0"

and the second one

"portvlan_add 200 128 99"

The user has to understand that 128 is the physical port ID of the
fron-plate port where he has plugged in a cable that he wants to be
assoicated with the interface sdn1. He also needs to understand that
he can assign any port ID to sdn1.99 as long as it doesn't overlap
with any physical port ID, which depends on the exact Tofino model he
uses.  For example, the range from 200 upward may be free for a 2-pipe
Tofino, but it isn't for a 4-pipe Tofino. He also needs to understand
that the parameters following the port ID for a sub-interface are
ignored.

There is just a lot of potential for confusion and mistakes (what if a
user *does* pick a physical port ID for a sub-interface?). I haven't
thought this through to the end, but it appears to me that we should
be able to let the selection of the port ID for sub-interfaces
entirely up to freerouter, then we wouldn't need an export-port stanza
for them at all.  This is trivial if the data-plane exposes the
port-name-to-ID mapping for all its ports, but it would also be
possible without that by using different number-spaces for these two
things (with corresponding logic in the P4 code to be able to make
that distinction).

Similarly, I don't see a fundamental reason why we should not be able
to treat all other "virtual" ports like this.

Is there anything here that I'm missing completely?

-- 
Alex

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