Rare project developers

[mc36 <>]

hi,
so the rest of the feature was just finished... here are the changes:
- the bmv2 code is much simpler:
  
https://github.com/mc36/freeRouter/commit/4d20fddfad9ef30a922ce26c48df63412513b3d5
- the tofino version is not too hard to read too, except the implicit header 
imposition:
  
https://github.com/mc36/freeRouter/commit/701cbcf7d351815d02508616cfd0d72061d3abdf
now a full re-test round is in progress here, then the mail to -users list...
regards,
cs


On 10/20/21 08:35, mc36 wrote:
> hi,
> so as the $subj$ suggests, things are happening... the story behind it is 
> that we started evaluating
> a more realistic scenario with frederic, involving some traffic generators 
> (so it was not the router
> itself who put the traffic to the tunnels, but the dataplane itself...) then 
> after several iterations
> and smaller fixes, we found out that the pbr at the moment is ip-only as you 
> can see below in the first
> run, it only have a nexthop and not the label, and the nexthop itself only 
> holds the layer2 rewrite info,
> and nothing about mpls, so a new knob (second run below) is needed, when the 
> label value (881070 here)
> is also propagated to the dataplane... after we found it out, it was quite 
> straightforward...
> as it's the -dev list, here is the progress:
> - first the freerouter control plane was touched to have the new messages:
>  Â Â Â  
> https://github.com/mc36/freeRouter/commit/9694f6f69f00b1ad8195f16e7a639d9683f5009f
> - then the p4emu (dpdk, pcap) got the capability to have the knob understood:
>  Â Â Â  
> https://github.com/mc36/freeRouter/commit/cd3df649859b0da0a0d2a69b65760c57a17072d6
> - finally the test cases were created for the new functionality covering the 
> possibilities:
>  Â Â Â  
> https://github.com/mc36/freeRouter/commit/43d6a30d745dd49125d494d735755a3da75d55fe
> the next steps will be in the bmv2 then the tofino dataplanes... these are as 
> small
> additions as the second commit to the p4emu dataplane (or even smaller) but 
> as these
> dataplane tests runs for a hour or so, it'll be slower to have a validated 
> code in place...
> long story short, with this, and the last time with the ipv6.flow things, 
> soon we can
> demo you something in the p4 testbed with realistic traffic... :)
> regards,
> cs
>
>
>
>
>
> On 10/20/21 04:32, mc36 wrote:
> > sid(cfg)#ipv4 pbr v2 sequence 10 asdf v2 nexthop 1.1.1.2
> > sid(cfg)#debug servP4lang.sendLine:servP4lang.java:617 tx: pbr4hop_add 2 2 
> > 29820 0 permit 1 255 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0 0 0 0
> > sid(cfg)#no ipv4 pbr v2 sequence 10 asdf v2 nexthop 1.1.1.2
> > sid(cfg)#debug servP4lang.sendLine:servP4lang.java:617 tx: pbr4norm_del 2 0 0 
> > 0 permit 1 255 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0 0 0 0
> > sid(cfg)#
> > sid(cfg)#
> > sid(cfg)#
> > sid(cfg)#ipv4 pbr v2 sequence 10 asdf v2 nexthop 1.1.1.125
> > sid(cfg)#debug servP4lang.sendLine:servP4lang.java:617 tx: pbr4lab_add 2 2 
> > 29820 881078 0 permit 1 255 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0 0 0 0
> > sid(cfg)#
> > sid(cfg)#no ipv4 pbr v2 sequence 10 asdf v2 nexthop 1.1.1.125
> > sid(cfg)#debug servP4lang.sendLine:servP4lang.java:617 tx: pbr4norm_del 2 0 0 
> > 0 permit 1 255 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0 0 0 0
> > sid(cfg)#