Rare project developers

[mc36 <>]

hi,
i made the frontpanel port names usable, but they'll be get converted to 
subifid immediately:
https://github.com/mc36/freeRouter/commit/8b04f34c32e9cd27f71ea7083c6cb13204baa809
but i cannot get rid of this behavior... okk, maybe i could, but right now, i 
have
no idea about a good solition... details below...
regards,
cs

sid(cfg-server)#show p4lang p4
category    value
peer        10.5.122.125
closed      0
since       2022-02-27 07:39:05
for         00:01:08
capability  copp acl racl inspect nat vlan bundle bridge pppoe hairpin gre l2tp route mpls vpls evpn eompls gretap pppoetap l2tptap vxlan ipip macsec ipsec pckoudp openvpn 
wireguard srv6 pbr qos flwspc mroute duplab bier amt nsh polka mpolka sgt
platform    p4emu/openssl/pcap
cpuport     0
dynamicid   128 65535
portid0     ens4
portid1     ens5
portid2     ens6
portid3     ens7
portid4     ens8

sid(cfg-server)#no  export-port sdn4 4 0 0 0 0
debug servP4lang.sendLine:servP4lang.java:696 tx: state 4 0 0 0 0 0
sid(cfg-server)#export-port sdn4 ?
  <num> - port number
  ens4  - port number
  ens5  - port number
  ens6  - port number
  ens7  - port number
  ens8  - port number

sid(cfg-server)#export-port sdn4 ens8 ?
  <cr>
  <num> - speed in gbps

sid(cfg-server)#export-port sdn4 ens8
sid(cfg-server)#debug servP4lang.sendLine:servP4lang.java:696 tx: state 4 1 0 
0 0 0
debug servP4lang.sendLine:servP4lang.java:696 tx: mtu 4 1500
sid(cfg-server)#show running-config this
server p4lang p4
 export-vrf v2 2
 export-port sdn1 1 0 0 0 0
 export-port sdn2 2 0 0 0 0
 export-port sdn3 3 0 0 0 0
 export-port sdn4 4 0 0 0 0
 interconnect pwether0
 vrf v1
 exit
!


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

so when startup config interpreted, these names are not available...


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

these are separate vms, doing only the dataplane thing:
in case of tofino, they're the bfswd, bffwd and that's all...
it is built with this recipe: 
https://github.com/mc36/freeRouter/blob/master/misc/p4bf/c-all.sh
(the commented out part is the vm creation process...)
in case of bmv2, they're built with 
https://github.com/mc36/freeRouter/blob/master/misc/p4lang/c.sh
in case of dpdk, pcap and xdp, they're built with 
https://github.com/mc36/freeRouter/blob/master/misc/p4emu/c.sh
they're acting the same regardless of the dataplane is in use:
the first vm nic is the linux mgmt, where they connect to freerouter's p4lang 
server...
the second vm nic is the cpuport where they speak the same cpuport protocol...
the rest of the vm nics are the front panel ports, which could be instructed 
from freerouter...
then the tests simply spawn up a qemu instance and takes the vm nics:
https://github.com/mc36/freeRouter/blob/master/cfg/p4lang-rout001.tst
r1 is the controlling freerouter with the p4lang configured, r2 is the
dataplane itself, that's why it's sw config is empty, and the rest are
surrounding routers connected to the dataplane vm nic ports....
then the tests to perform, and finally a longer ping to see if the
software counters not moving too much...
but the dataplanes report different frontpanel port names...
here i started the same test with multiple dataplanes:

mc36@safe:/data.pub/src$ java -Xmx512m -jar rtr.jar test tester 
p4lang-rout001 other p4lang1.ini wait
mc36@noti:~$ telnet devel 20001
Trying 2001:db8:1005:255:200:11ff:fe11:2222...
Trying 10.5.255.1...
Connected to devel.
Escape character is '^]'.
welcome
line ready
r1#show p4lang p4
category    value
peer        10.11.12.111
closed      0
since       2022-02-27 07:11:56
for         00:03:33
capability  copp acl racl inspect nat vlan bundle bridge pppoe hairpin gre l2tp route mpls vpls evpn eompls gretap pppoetap l2tptap vxlan ipip macsec ipsec pckoudp openvpn 
wireguard srv6 pbr qos flwspc mroute duplab bier amt nsh sgt
platform    bmv2
cpuport     -3
dynamicid   512 1023
portid0     bmv2-port0
portid1     bmv2-port1
portid2     bmv2-port2
portid3     bmv2-port3
portid4     bmv2-port4
portid5     bmv2-port5
portid6     bmv2-port6
portid7     bmv2-port7
portid8     bmv2-port8
portid9     bmv2-port9

r1#

mc36@safe:/data.pub/src$ java -Xmx512m -jar rtr.jar test tester 
p4lang-rout001 other p4lang2.ini wait
mc36@noti:~$ telnet devel 20001
Trying 2001:db8:1005:255:200:11ff:fe11:2222...
Trying 10.5.255.1...
Connected to devel.
Escape character is '^]'.
welcome
line ready
r1#show p4lang p4
category    value
peer        10.11.12.111
closed      0
since       2022-02-27 07:16:17
for         00:01:46
capability  copp acl racl inspect nat vlan bundle bridge pppoe hairpin gre l2tp route mpls vpls evpn eompls gretap pppoetap l2tptap vxlan ipip macsec ipsec pckoudp openvpn 
wireguard srv6 pbr qos flwspc mroute duplab bier amt nsh polka mpolka sgt
platform    p4emu/openssl/pcap
cpuport     0
dynamicid   128 65535
portid0     ens4
portid1     ens5
portid2     ens6
portid3     ens7
portid4     ens8

r1#


mc36@safe:/data.pub/src$ java -Xmx512m -jar rtr.jar test tester 
p4lang-rout001 other p4lang4.ini wait
mc36@noti:~$ telnet devel 20001
Trying 2001:db8:1005:255:200:11ff:fe11:2222...
Trying 10.5.255.1...
Connected to devel.
Escape character is '^]'.
welcome
line ready
r1#show p4lang p4
category    value
peer        10.11.12.111
closed      0
since       2022-02-27 07:18:38
for         00:00:20
capability  route mpls bundle vlan pppoe eompls bridge vpls evpn
platform    p4xdp
cpuport     0
dynamicid   32768 65535
portid0     xdp-port3
portid1     xdp-port4
portid2     xdp-port5
portid3     xdp-port6
portid4     xdp-port7

r1#


the thing to notice here is that the names of the ports are different so if 
we would
allow only names for the portid range then we cannot use the same tests for 
all the
dataplanes because then the export-port stanza must contain the name....



> 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"
okk so underlining the can, it's fulfilled for now imho.... :)


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

right now, the dynamic range is also user managed...
there will still be special interfaces that need to be exported,
but my idea for them now is to allow the knob "dynamic" where we
accept frontpanel names or mostly subifids... these are pppoe
virtual accesses, tunnels, hairpins, and basically everything
that is not sdn interface... we already scan the available interfaces
for virtual-accesses, i can easily extend that part to subinterfaces too...
the dataplanes already inform freerouter of the dynamic ranges they
support so it seems easy-peasy as said before... that'll be the
next pokemon to catch... :)



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