Rare project developers

[mc36 <>]

one thing to note... try to not depend on external libs to eachoeve that, for 
example i have some poly algos in src/cry/cryHashCrc16 or cryHashHec for atm 
cells....
thanks,
cs

On 4/7/21 6:44 PM, mc36 wrote:
> hi,
>
> On 4/7/21 4:30 PM, Rafael S. Guimarães wrote:
> [..]
>
> > Sure, a meeting would be amazing. We appreciate a lot your help in thisway, and, of course, to ease us in understanding the whole Freertr code. Further, we can know how we 
> > effectively contribute (git and tests) to the Freertr. I will do my best to move our effort forward in developing the Java part :).
> you're welcomed on the board! :)
>
> > So, what do you think to have a meeting next week? 
>
> so, as usual, surely, hell yeahh.... :)
>
>
> > What time/day would be better for you?
>
> imho anytime, as usual, please pick a date, but please allow me to cancelsome 
> hours before....
> (i have a lot to sleep these days...:()
>
> > I don't know your timezone, but from my side is UTC -3  (Brazil/Sao 
> > Paulo time).
>
> i'm in +0100 or, i donno if we left summer/winter time yet, it's CET/CEST
>
> mc36@noti:~$ cat /etc/timezone
> Europe/Budapest
> mc36@noti:~$
>
>
>
>
>
> >  >  that your stuff will be configurable like an srte tunnel, but with a 
> > different layer2.5.... am i wrong on that?
> >
> > Yes, indeed, the original PolKA header is between ethernet and IPv[46] headers. But, we can think together if you want/suggest other ways to integrate it, aiming the protocol 
> > evolution in a fancy and production way.
>
> hmmm, at the moment, i just briefly read dominicini2020.pdf , from that, my 
> idea was that it's a layer2 source routing....
> but i'm far from suggesting other use cases than that... but..... if we move 
> forward, and, your forwarder will integrate
> to freertr java stuff then, for example, you'll have autoroute through the 
> tunnel interface of yours... we'll have nothing
> to do for that, it's automatic graft being part of the java stuff... and it 
> inherits to the p4 part too, if we proceed to
> servP4lang after we got the qc-passed vignette from the board :)
>
>
> > BTW, Frederic and Jordi are already organizing my access to the repository. I 
> > am in touch with them via Slack.
>
> i'm much more interested in signal these days... you can find my reachability 
> at mc36.nop.hu
> but some things to note...
> 1) if signal does not connect immediately, try again later, that's just the best-effort 
> delivery "effect" (khm) of the net :)
> 2) i just not yet started moving to lineage 18.1 on my cell where i mostly 
> run signal, so that's why
> i would go for a quick chat about 2 weeks later...
>
> until that, please think about how would you handle the following situation.
> you'll have to come up with a function
>
> public boolean gotPolka(packHolder pck) {
> ///parse your header here, log every error using logger.error("wtf"); , we'll 
> assign proper levels later... :)
> //as i saw you can have different bit sizes in the header, imho it's the same 
> as bier's 256 and 4k mode?
> //when you need to know a bit's route, you can stick yourself to ipFwd's 
> actualU. each one resolves to
> //a tabRouteEntry, where, you'll find your bit in, then you'll have to pick 
> the best and use that attrib's
> //segrouIdx.. to have the header bit size, you can use segrouSiz field from 
> the same attrib class...
> //you may need some additional fields, feel free to look around in the above 
> mentioned tabRouteAttr class..
> //if you think about this way, polka will be a drop-in replacement for 
> mpls-sr, seamless mpls-sr and so on...
> }
>
>
> thanks,
> cs
>
>
>
>
> > Best regards,

> > Rafael
> >
> >
> >
> > Â Â Â  On 4/2/21 9:32 PM, Rafael S. Guimaraes wrote:
> >      > Hi @Csaba,
> > Â Â Â Â  >
> > Â Â Â Â  > Sorry for my late reply. I was struggling this week with some 
> > tasks running in parallel.
> > Â Â Â  np, i also took an offline weekend :)
> >
> > Â Â Â Â  >
> >      >  > if you would 'handle over' (abandon) the current work as is, 
> > then go with a single pull-req... we'll move forward as sde95 appears soon, in that 
> > case, we'll who will
> > Â Â Â  ensure that
> > Â Â Â Â  > it compiles and passes the tests in the future...
> > Â Â Â Â  >
> >      > I have created a new branch (polka) after cloning the RARE 
> > bitbucket repo, and I am working on this branch locally.
> > Â Â Â Â  >
> >      >  > alternatively if you plan to support polka in longrun 
> > @RARE/FreeRTR, then we can
> > Â Â Â Â  > arrange you rw access to the main repos after the initial pull-req 
> > & merge then
> > Â Â Â Â  > both of us will patch the stuff: as freertr internal apis 
> > evolvethen i'll easily
> > Â Â Â Â  > move forward and update your forwarder parts also, then update the 
> > api messages
> > Â Â Â Â  > and the dpdk & p4 code if needed... and if you change your mind 
> > then you'll also
> > Â Â Â Â  > be able to change these parts....
> > Â Â Â Â  >
> > Â Â Â Â  > For me, it is a good alternative! From my perspective, once we have some way 
> > to fork and submit a pull request, we can be more "relaxed" to work because you 
> > will be
> > Â Â Â Â  > verifying/analyzing the code before merging and making sure thatmy 
> > pull requests are not breaking/messing the code.
> >
> > Â Â Â  feel free to work on that, frederic will arrange you an rw access.
> > Â Â Â  from my side, that repo is just a write-only backup of 
> > sources.nop.hu/misc/p4bf <http://sources.nop.hu/misc/p4bf>
> > Â Â Â  that is, once you run the upgrade scripts then your change will be 
> > overwritten....
> > Â Â Â  so, once you did your tests, please notify me, i'll check the diffs, 
> > verify them,
> > Â Â Â  and if i cannot spot a thing, i'll update my /misc/ directory with 
> > your new sources....
> > Â Â Â  is this constrain acceptable for you?
> >
> >
> > Â Â Â Â  >
> >      >  > so if i understand you correctly, you already havesomething 
> > that works!  at least, in p4... and if i understand you correctly, you 
> > already have some bfforwarder.py
> > Â Â Â  messages
> > Â Â Â Â  > that program the dataplanes... on top of these, it's hard to write 
> > a self test imho, we'll need the pure java version implementing the 
> > forwarding... to have something that
> > Â Â Â  can be
> > Â Â Â Â  > tested against itself, and then to test the dataplane vms against 
> > that...
> > Â Â Â Â  >
> >      > Yes, you are correct!  Do you think we can do it by steps, 
> > for example, commit the P4 and bf_forwarder.py (data- and control-planes), which 
> > we already have done, and after
> > Â Â Â Â  > developing and pushing the commit of the Java part (user 
> > interface) we think about end-to-end tests?
> > Â Â Â Â  >
> >
> > Â Â Â  please move forward with the java part, please, please! :)
> > Â Â Â  i mean just the core forwarding and let me do the rest...
> > Â Â Â  if you have spare time, we could have a meeting and i'll tell you the 
> > dirty details to ease your work....
> > Â Â Â  from that point, once you coded the very core of your idea, then let 
> > me do the rest for you....
> > Â Â Â  that is, the surrounding user interface, tests, everything!
> > Â Â Â  my idea is that your stuff will be configurable like an srte tunnel, 
> > but with a different layer2.5.... am i wrong on that? :)
> >
> >
> >      >  > if you could point me to your repo, then I can have some 
> > more idea on how to proceed...
> > Â Â Â Â  >
> > Â Â Â Â  > I have created a gist code for that. I was not sure and a bit 
> > concerned whether I am allowed or not to clone and put your RARE repo in our 
> > Github repository. That's why I
> > Â Â Â  decided
> > Â Â Â Â  > to keep all the changes locally in my cloned repo.
> > Â Â Â Â  >
> > Â Â Â Â  > https://gist.github.com/rafaelsilvag/727507e96849af3de7ad10082c7d7f86 
> > <https://gist.github.com/rafaelsilvag/727507e96849af3de7ad10082c7d7f86>
> > Â Â Â  <https://gist.github.com/rafaelsilvag/727507e96849af3de7ad10082c7d7f86 
> > <https://gist.github.com/rafaelsilvag/727507e96849af3de7ad10082c7d7f86>>
> >
> > Â Â Â  i'll check if a bit later a bit more deeper, but for the first insight, it'll 
> > have the "qc passed" vignette.... :)
> >
> >
> > Â Â Â Â  >
> >      > So, do you think that we can start working like as you said 
> > before (fork and pull-requests)?
> > Â Â Â Â  >
> >
> > Â Â Â  imho frederic will arrange you the rw access to the bitbucket 
> > somehow.... :)
> >
> > Â Â Â  thanks,
> > Â Â Â  cs
> >
> >
> >
> >
> > Â Â Â Â  > Best regards,
> > Â Â Â Â  > Rafael
> > Â Â Â Â  >
> > Â Â Â Â  > On Fri, 26 Mar 2021 at 11:16, mc36 < <> 
> > < <>>> wrote:
> > Â Â Â Â  >
> >      >     hi,
> > Â Â Â Â  >
> >      >     On 3/26/21 2:27 PM, Rafael S. Guimaraes wrote:
> >      >      > Hi @Csaba,
> >      >      >
> >      >      > Thanks for pointing thatout. You are right! We 
> > have already done the data- and control plane parts (bf_router.p4 and 
> > bf_forwarder.py).
> > Â Â Â Â  >
> >      >     excellent!
> > Â Â Â Â  >
> >      >      >
> >      >      > My question is: after successfully compiling on those platforms (BMv2, Tofino, and DPDK), what should the next steps be? Can I drop a 
> > pull-request to the
> > Â Â Â  main repository,
> >      >     or must
> >      >      > we use a different branch, the 
> > "polka" one, as an example? We freeze the P4 SDE version 9.4.0 in 
> > our deployment phase.
> > Â Â Â Â  >
> >      >     it depends....
> > Â Â Â Â  >
> >      >     if you would 'handle over' (abandon) the current work 
> > as is, then go with a single pull-req...
> >      >     we'll move forward as sde95appears soon, in that 
> > case, we'll who will ensure that it
> >      >     compiles and passes the tests in the future....
> > Â Â Â Â  >
> >      >     if you already have that repo somewhere, you can 
> > still make the pull-reqs when
> >      >     you change a thing here & there.... but i'll be 
> > trickier to keep them in sync....
> > Â Â Â Â  >
> >      >     alternatively if you plan to support polka in long 
> > run @ rare/freertr then we can
> >      >     arrange you rw access to the main repos after the initial 
> > pull-req & merge then
> >      >     both of us will patch the stuff: as freertr internal 
> > apis evolve then i'll easily
> >      >     move forward and update your forwarder parts also, 
> > then update the api messages
> >      >     and the dpdk & p4 code if needed... and if you change 
> > your mind then you'll also
> >      >     be able to change these parts....
> > Â Â Â Â  >
> > Â Â Â Â  >
> >      >      >
> >      >      > Thanks for providing some hints about the Freertr 
> > development step. It is the part of the integration that we did 
> > have no clue on how to proceed.
> > Â Â Â Â  >
> >      >     so if i understand you correctly, you already have 
> > something that works!
> >      >     at least, in p4... and if iunderstand you correctly, 
> > you already have some
> >      >     bfforwarder.py messages that program the dataplanes...
> >      >     on top of these, it's hard to write a self test imho, 
> > we'll need the pure
> >      >     java version implementing the forwarding... to have 
> > something that can be
> >      >     tested against itself, and then to test the dataplane 
> > vms against that...
> > Â Â Â Â  >
> >      >     if you could point me to your repo, then i can have 
> > some more idea on how to proceed...
> > Â Â Â Â  >
> >      >     thanks,
> >      >     cs
> > Â Â Â Â  >
> > Â Â Â Â  >
> > Â Â Â Â  >
> > Â Â Â Â  >
> >      >      >
> >      >      > Kind regards,
> >      >      > Rafael
> >      >      >
> >      >      >
> >      >      > On Thu, 25 Mar 2021 at 10:59, mc36 < <> 
> > < <>> < <> <
> > Â Â Â  <>>>> wrote:
> >      >      >
> >      >      >     hi,
> >      >      >
> >      >      >     On 3/25/21 1:51 PM, 
> > Rafael S. Guimaraes wrote:
> >      >      >
> >      >      >      >
> >      >      >      > @Csaba, feel free to 
> > contact me any time!
> >      >      >      >
> >      >      >
> >      >      >     at the moment all i 
> > knowis that sent on this public mailing and my own research (your paper fromdoi 
> > search engines:))
> >      >      >
> >      >      >     knowing these, you should 
> > have come up with a p4 dataplane integration into
> >      >      >     - http://sources.nop.hu/misc/p4lang/ 
> > <http://sources.nop.hu/misc/p4lang/> <http://sources.nop.hu/misc/p4lang/ 
> > <http://sources.nop.hu/misc/p4lang/>>
> > Â Â Â  <http://sources.nop.hu/misc/p4lang/ <http://sources.nop.hu/misc/p4lang/> 
> > <http://sources.nop.hu/misc/p4lang/ <http://sources.nop.hu/misc/p4lang/>>> for bmv2
> >      >      >     - http://sources.nop.hu/misc/p4bf/ 
> > <http://sources.nop.hu/misc/p4bf/> <http://sources.nop.hu/misc/p4bf/ 
> > <http://sources.nop.hu/misc/p4bf/>>
> > Â Â Â  <http://sources.nop.hu/misc/p4bf/ <http://sources.nop.hu/misc/p4bf/> 
> > <http://sources.nop.hu/misc/p4bf/ <http://sources.nop.hu/misc/p4bf/>>> for tofino
> >      >      >     - http://sources.nop.hu/misc/native/ 
> > <http://sources.nop.hu/misc/native/> <http://sources.nop.hu/misc/native/ 
> > <http://sources.nop.hu/misc/native/>>
> > Â Â Â  <http://sources.nop.hu/misc/native/ <http://sources.nop.hu/misc/native/> 
> > <http://sources.nop.hu/misc/native/ <http://sources.nop.hu/misc/native/>>> for 
> > dpdk/libpcap
> >      >      >     if i understand flou's 
> > words correctly, you're done with some of that already:)
> >      >      >     and you should have to 
> > proceed with the configuration parts...
> >      >      >     some hints here are how
> >      >      >     - rsvp-te 
> > http://sources.nop.hu/src/clnt/clntMplsTeP2p.java 
> > <http://sources.nop.hu/src/clnt/clntMplsTeP2p.java>
> > Â Â Â  <http://sources.nop.hu/src/clnt/clntMplsTeP2p.java 
> > <http://sources.nop.hu/src/clnt/clntMplsTeP2p.java>> 
> > <http://sources.nop.hu/src/clnt/clntMplsTeP2p.java
> > Â Â Â  <http://sources.nop.hu/src/clnt/clntMplsTeP2p.java>
> >      >     <http://sources.nop.hu/src/clnt/clntMplsTeP2p.java 
> > <http://sources.nop.hu/src/clnt/clntMplsTeP2p.java>>>,
> >      >      >     - sr-te 
> > http://sources.nop.hu/src/clnt/clntMplsSr.java 
> > <http://sources.nop.hu/src/clnt/clntMplsSr.java> 
> > <http://sources.nop.hu/src/clnt/clntMplsSr.java
> > Â Â Â  <http://sources.nop.hu/src/clnt/clntMplsSr.java>> 
> > <http://sources.nop.hu/src/clnt/clntMplsSr.java 
> > <http://sources.nop.hu/src/clnt/clntMplsSr.java>
> >      >     <http://sources.nop.hu/src/clnt/clntMplsSr.java 
> > <http://sources.nop.hu/src/clnt/clntMplsSr.java>>>,
> >      >      >     - srv6 
> > http://sources.nop.hu/src/clnt/clntSrExt.java 
> > <http://sources.nop.hu/src/clnt/clntSrExt.java> 
> > <http://sources.nop.hu/src/clnt/clntSrExt.java
> > Â Â Â  <http://sources.nop.hu/src/clnt/clntSrExt.java>> 
> > <http://sources.nop.hu/src/clnt/clntSrExt.java 
> > <http://sources.nop.hu/src/clnt/clntSrExt.java>
> >      >     <http://sources.nop.hu/src/clnt/clntSrExt.java 
> > <http://sources.nop.hu/src/clnt/clntSrExt.java>>>
> >      >      >     implemented in freertr to 
> > have the similar config interface for polka.
> >      >      >     also to automate the 
> > dataplane testing, it would be nice if you could
> >      >      >     come up with a pure 
> > javaforwarder, hint here how nsh/mpls done:
> >      >      > http://sources.nop.hu/src/ip/ipMpls.java 
> > <http://sources.nop.hu/src/ip/ipMpls.java> <http://sources.nop.hu/src/ip/ipMpls.java
> > Â Â Â  <http://sources.nop.hu/src/ip/ipMpls.java>> 
> > <http://sources.nop.hu/src/ip/ipMpls.java <http://sources.nop.hu/src/ip/ipMpls.java> 
> > <http://sources.nop.hu/src/ip/ipMpls.java
> > Â Â Â  <http://sources.nop.hu/src/ip/ipMpls.java>>>
> >      >      >
> >      >      >     if you have any questions 
> > or something to commit to,
> >      >      >     feel free to drop over 
> > the fence and we'll see how to proceed... :)
> >      >      >
> >      >      >     thanks,
> >      >      >     cs
> >      >      >
> > Â Â Â Â  >