Rare project developers

[mc36 <>]

hi,

On 7/14/22 17:55, Alexander Gall wrote:
> > the other thing is when you swap
> > the dataplanes: we have dpdk, pcap, xdp, all interchangeable both in
> > parameters, and so on... but they have different namings for the
> > interfaces, at least...
>
> I don't understand this argument. The p4lang section is specific to
> the p4 dataplane, isn't it?
yesss, it is, which nowadays, include the tofino, but we do have the dpdk,
epbf/xdp, pcap, and an udp based one, and all names their ports differently...
pcap uses the linux interface names:
noti#show p4lang p4 port-names
num | name
0   | enp0s31f6
2   | veth0b
3   | veth1b
1   | veth2b

noti#

on the other hand, dpdk uses the pcie ids (and in that case, linux interfaces 
does not exists at all):
nas#show p4lang p4 port-names
num  name
0    0000:00:1f.6
1    0000:01:00.0
2    0000:01:00.1
3    net_af_packet0
4    net_af_packet1
5    net_af_packet2
6    net_af_packet3
7    net_af_packet4
8    net_af_packet5
9    net_af_packet6

nas#

finally, ebpf/xdp uses interface indexes:
wifi>show p4lang p4 port-names 1
num | name
2   | idx#151
3   | idx#152
1   | idx#167
0   | idx#4
4   | idx#5
5   | idx#7
6   | idx#8

wifi>

and all these dataplanes are interchangeable, so one can switch between them 
by just modifying the processes to spawn in -hw.txt.
for example, an external forwarder compiled for openwrt can use the p4emu or 
the p4xdp... the first offers much more but performs
much slower... spinning them up differs just a bit in openwrt config sections:
https://github.com/rare-freertr/freeRtr/blob/master/misc/openwrt-p4emu/config
https://github.com/rare-freertr/freeRtr/blob/master/misc/openwrt-p4xdp/config

wifi>show p4lang p4 status 0 | include capa|plat
2022-07-14 18:53:36
capability    | punting copp acl 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 racl inspect mpolka sgt vrfysrc gtp loconn tcpmss pmtud
platform      | p4emu/pcap

wifi>show p4lang p4 status 1 | include capa|plat
2022-07-14 18:53:40
capability    | punting route mpls bundle vlan pppoe eompls bridge vpls evpn 
hairpin sgt loconn
platform      | p4xdp

wifi>


after this, all the dataplanes speak the same protocol with freerouter to 
have the forwarding info....
and this, at least, used within the dataplane tests heavily: we have that 
~500 set of configs,
and all could be executed against the different forwarders:
-the tofino emulator
-the p4emu forwarder coupled with dpdk, pcap or udp packetio
-the ebpf/xdp for full in-kernel forwarding
-the libmnl for switchdev based boxes



> Sorry, I didn't follow the whole stacking thing, so can't comment
> about this specifically. 
so as we have multiple dataplanes, these could be connected to act as single 
entity,
much like it happened with stacking, or as you do in apic, or as you imagine 
it happens
in a chassis based box... but, these dataplanes offer different capabilities, 
and,
if you think about in a chassis based system, some components does not 
require all
the tables being exported... for example, the interconnect really only needs 
the
mpls table, and the linecards require only local ports... but, there is a big 
difference
if an entity can, or should perform a given operation... in my case, there is 
a 2x
difference if my aps try to do the routing too, compared if they only perform 
bridging...
(binary search in a small, ordered table vs a full lpm lookup on a 128bit key 
on an 2k
sized rib on an embedded ramips soc boxes)... and then we arrived to the 
virtual
interfaces like hairpin, tunnel, vaccess interfaces cloned from pppoe or 
l2tp, etc:
it's a reasonable decision that one exports the outside vrf (and source 
interface)
only on forwarders having core facing interfaces, and exports the inner vrf 
(and
resulting cloned interfaces) only on forwarders with user facing interfaces...
it's a thing one cannot guess alone without having knowledge about the 
network...

> I'm just worried that this complexity will
> cause serious problems for users. People are already pretty confused
> about the entire export-* stuff for p4, which is why we try to make
> this more automatic. It seems to me that we should have some kind of
> unified "parameter negotiation" between the various dataplanes and
> freerouter to remove the burden on the user as much as possible and
> make the configuration more uniform across dataplanes.

well, now think about the above.. surely it's not too hard to export
everything belonging to a given set of ports but the other side will
be the loss in possibilities...


br,
cs