Rare project developers

[Alexander Gall <>]

Hi

On Fri, 25 Feb 2022 10:31:00 +0100, mc36 <> said:

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

Not sure what you mean. The ID is still there, either the way it is
now (physical port ID determined by the user) or replaced by a more
user-friendly identifier (e.g. "1/0" for the Tofino DP) which is
translated to the physical ID automatically. What kind of validation
is no longer possible?

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

You really lost me here since I'm not familiar with how your test
cases work. Can you please elaborate?  I don't see how what I'm
proposing has any effect on this in case of the Tofino DP. The only
things that would change are

   * The user can use meaningful names in "export-port" for physical
     ports, e.g. "1/0"

   * The user doesn't have to create "export-port" stanzas for
     sub-interfaces explicitely

How would this change the output of your test cases?

> the same issue will appear if you swap the p4pcap and p4dpdk dataplanes
> on a physical box... (they are normally fully interchangeable!)

I agree that would be bad but I don't unserstand why this would
happen.

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

Correct, but that would actually be a good thing, IMHO. For example,
the counters for VLANs are currently arranged in an array indexed by
the number space shared by the pseudo-port and physical-port IDs but
only the indexes corresponding to pseudo-ports will ever be used. I.e
we're wasting hundreds of counters. What we should do is to define how
many VLANs we're supporting in the HW, which would determine how large
that array is and how many pseudo-ports freerouter can use to assign
to sub-interfaces for the Tofino DP.

-- 
Alex

> 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?
>> 
-- 
SWITCH
--------------------------
Alexander Gall, Network
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 15 22
, http://www.switch.ch