RARE user and assistance email list

[mc36 <>]

hi,

On 8/29/20 9:51 AM, Frédéric LOUI wrote:
> >   the first one that depends on the recirculation,
>
> IIRC, in the VM I gave you, you’ll see a « resubmit » example from 
> INTEL/BAREFOOT.
> As per BA-102 training, it is strictly the same in terms of code 
> implementation. You can get a good grasp of it.
> If needed, we can ask some help in FASTER portal. I had the confirmation that 
> KIFU is INTEL/BAREFOOT partner.
> Is Janos gave you access to BAREFOOT/FATER portal ? If not can he gives you 
> access to it ? The process is straightforward.
no and he seems too busy to do so... you well know we alrady asked him 
hundred times....
can you instead enroll me under your organizational account? :)

> > second part are simply a kind of nexthop … seems easy-peasy
>
> This is re-assuring. It could be great though to have this mainstream in a PE 
> SDM, or if the it fits into the NPU to have this in the default MPLS SDM.
> Or maybe this would make more sense to create a BRAS SDM.
we'll see what fits and what don't but yess, we could have since pppoe is 
also a nexthop (and a control also...)
i'm currently thinking about that since i'm planning to protect all the 
features -except very basic ones- with
ifdef directives, the user can choose what to include and what not... but 
yess, we could give them some precompiled
sdm profiles with some selected features enabled in them....

regards,
cs



> > Le 29 août 2020 à 06:25, mc36 <> a écrit :
> >
> > hi,
> >
> >
> > On 8/28/20 6:48 PM, Frédéric LOUI wrote:
> > > Hi
> > > Great !
> > > My KVM_ONIE VM was not useless after all :)
> > absolutely!!!
> >
> > > So this is nice, because that we can have a dynamic feature set in a list for 
> > > that I can integrate in the RARE WIKI.
> > the newer ones are 'nicer', you'll see... :)
> >
> > > By dynamic, I mean that in a CI way:
> > > * each commits
> > > * adding new features
> > > * will trigger test against TNA (bf_switchd) platform
> > > * these test results reflect the features list and their status. (RFS or not )
> > external ci tools would go crazy with this: it takes 2 hours to run on the 
> > current
> > p4 feature list, requires a lot of cpu, ram and diskio because of the qemu 
> > instances
> > continously spawned and stopped, and the most critical, requires the image(s) 
> > to be
> > present in the ci environment, and surely the execution of my tester, since 
> > i've
> > not aware of any other automatic testing solution that does anything similar 
> > this... :)
> >
> > > Note that due to the use case nature, there will be some RARE/freeRouter 
> > > profile (SDM)
> > > For example, we have SDM=MPLS, SDM=SRv6
> > > In some cases having GRE or NAT at 100GE makes no senses, some we will have 
> > > more SDM.
> > > i.e All the features that boast BMv2 cannot enter into TOFINO. BMv2 has 
> > > virtually no memory/resources constraints which is not the case for TOFINO. 
> > > So we will end up in various SDM profiles for TNA architecture having a 
> > > subset of features of the whole feature set that BMv2/P4DPDK  has.
> > to be honest, nat is straightforward since it's just another control executed 
> > at the right place,
> > and all the infra needed for it is the acls, and that's already there so i 
> > modularized bridging
> > in the bfswd code like we modularized mpls and srv6 to have some stages so 
> > yess, i'm planning to
> > add nat as an option soon...
> > also introduced features in my auto-tester by the way we discussed yesterday 
> > that is, images now
> > describe which features they provide and test cases describe which features 
> > they require and a
> > test is onyl started if requirements meets provided features... it's a huge 
> > speedup for my runs
> > on bfswd butt opens up the possibility for me to have more images for a test 
> > set and the tester
> > be able to sselect one that believed to be albe to execute it successfully... 
> > as soon as i'll
> > get to the nat on bfswd part, it'll happen...
> >
> > regarding the rest of these features introduced recently, they fall on three 
> > categories: the
> > first one that depends on the recirculation, which started with hairpin and 
> > believed that we have
> > in tofino so since i have now a convenient development environment for bfswd, 
> > will give it a try...
> > the second part are simply a kind of nexthop, for example gre, pppoe and l2tp 
> > (and vxlan will be
> > the same!) so surely seems easy-peasy... the third category is the mix of the 
> > two above.... :)
> >
> > regards,
> > cs
> >
> >
> > > Thanks for this excellent job Csaba !
> > > À bientôt,
> > > --  Frederic
> > > > Le 28 août 2020 à 18:34, mc36 <> a écrit :
> > > >
> > > > hi,
> > > > finally got a working tester vm with barefoot tofino emulator installed 
> > > > within...
> > > > it runs exactly the same binary generated from the same p4s as our wedge 
> > > > switches...
> > > > please find attached the test runs against it... don't be scared of the lot of
> > > > failing ones, those features are simply not available in our current tofino p4
> > > > code tree  (or not enabled in the tested mpls sdm profile, like srv6), but all
> > > > exists for bmv2 so each could be implemented, and some are already selected to
> > > > arrive sooner or later...
> > > > regards,
> > > > cs
> > > > <bfswd.html>