Rare project developers

[mc36 <>]

hi,
still interesting questions....
so let's assume for now if we drop the portid thingy completely from the 
export-port stanzas....
for this to happen, we have to use the sdn--portname mapping from the 
dataplanes...
then p4lang server loses the possibility to validate the config before the 
dataplane connects in....
right now i see it making life harder to test the dataplanes indepently.. 
right now i have several
dataplane vms that use portid0..3 and the tests written for them using the 
portid mapping...
if we drop the portid stuff, it'll make testing almost impossible because
tofino reports X/0, bmv2 reports bmv2-portX, xdp reports xdp-portX,
p4pcap reports enoX, and p4dpdk reports 0000:0X.0...
so one cannot write a common test case for all the dataplanes....
the same issue will appear if you swap the p4pcap and p4dpdk dataplanes
on a physical box... (they are normally fully interchangeable!)
regarding subinterfaces and the dynamic port range, it's not impossible to 
achieve,
the only missing part here is the dataplanes need to report the available 
subinterface
id range they can accommodate without confusing them to physical port ids...
regards,
cs



On 2/25/22 10:04, Alexander Gall wrote:
> 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?