Rare project developers

[mc36 <>]

hi,

On 7/15/22 17:35, Alexander Gall wrote:
> On Thu, 14 Jul 2022 19:02:42 +0200, mc36 <> said:
>
> > 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,
>
> Just to make sure my understanding is correct: these dataplanes all
> use the same message format as the p4-specific bf_forwarder and all
> use the server p4lang stanza for configuration. The actual dataplane
> to be used is chosen by starting a specific forwarder and tying it to
> a p4lang instance (via rtr-hw).
>
> Freerouter is not aware of which dataplane it's actually talking to.
exactly! these all are fully interchangeable with very small changes here & 
there....

> It might be time to rename this into "server dataplane" or something
> :)
well, if it was the first try, then definitely i would go that way, but 
fortunately or not,
there is also an other server, openflow, with very similar syntax:
https://github.com/rare-freertr/freeRtr/blob/d8a52ca52da8caa7df6ed62c665770fe7c7fa154/cfg/opnflw-rout02.tst#L56
it's still supported and tested with an openvswitch dataplane vm...


> > and all these dataplanes are interchangeable, so one can switch between them 
> > by just modifying the processes to spawn in -hw.txt.
>
> This is where things get a bit murky for me.  First of all, in the
> case of Tofino, there actually is only one dataplane and these
> conflicts cannot occur. But, ok, this can be viewed as a special case.
right, moreover tofino based deployments can benefit from using the names:
then the switches themselves become replaceable if one uses the names
instead of the dataplane port ids...

> Each dataplane uses some kind of intrinsic identifier for an
> interface. For Tofino it's the "dev port", dpdk uses the PCI address
> etc. Before your recent change one had to enter those identifiers in
> the export-port clause. Or so I thought up to now (guess what, I have
> never used anything else than Tofino :). In the case of Tofino that's
> true. But for the other dataplanes, I think what's happening is that
> they have an array of interfaces and the number one enters with
> export-port is simply the index into that array. Is this correct?  At
> least that's the number that's mapped to the name with the new
> "portname" mechanism, AFAICS.
yesss, we can safely assume that there is such an array that maps names to 
indexes...

> Your argument then appears to be that if we used the names (which are
> essentially the intrinsic identifiers) instead of the number, that
> name would become meaningless if we switch to another dataplane while
> the number would be universal. Is that what you mean?
yess, in some cases yesss... for example the dpdk dataplane cannot do
a thing because dpdk's eal is who enumerates the usabe nics... it starts
with the physical ones, names them by their pcie id, and continues with
the virtual ones, and it names them like net_af_packetX...

on the other hand, the libpcap based forwarder uses the os interface names...

and finally the ebpf/xdp forwarder sees only the os interface indexes...

> But then I really don't understand how that can be true in
> general. Wouldn't that imply that the dataplane you switch to must see
> exactly the same devices and they would have to be in the same order,
> too? How can you be sure that's true?  Maybe your test cases just
> happen to be constructed that way or?
so yesss, for the numbers to work, one have to ensure that the numbering is 
the same...
if you switch from dpdk to anything, you have to give the interfaces to 
p4emu/p4xdp
in exactly the same order as dpdk would do: starting with the physicals then 
follow
them by the virtuals... if that is satisfied then the swap will work... if 
not, then
it'll fail and you have to re-order in the rtr-hw.txt or in p4lang server...

but, if one is forced to use the names, there would not be such a possibility 
because
there is no way that 0000:1f:00.1 (the dpdk name) would match to enp3 (the os 
name)...

and finally yeahh, all the dataplane tests are mentioning only the numbers, 
and
one constructs different vms for the different dataplanes one wants to test, 
and
just the startup script of these vms differs... here is mine which work fine:
https://github.com/rare-freertr/freeRtr/blob/master/misc/p4emu/r-dpdk.sh
https://github.com/rare-freertr/freeRtr/blob/master/misc/p4emu/r-pcap.sh
https://github.com/rare-freertr/freeRtr/blob/master/misc/p4emu/r-xdp.sh
and finally the tofion model one: 
https://github.com/rare-freertr/freeRtr/blob/master/misc/p4bf/ports.json



> > From a user perspective, this seems to have even more potential for
> confusion.  For Tofino, at least you can go check with bfshell which
> port a number represents. For other dataplanes, how would you figure
> out which interface
>
>   export-port sdn1 13
>
> refers to?
so all the dataplanes report the ports, so the netadmin always have
a meaningful output in sho p4 p4 port-names:

noti#show p4lang p4 port-names
num | name
0   | enp0s31f6
2   | veth0b
3   | veth1b
1   | veth2b

noti#


br,
cs