Rare project developers

["Rafael S. Guimaraes" <>]

Hi @Csaba,

Sorry for my late reply. I was struggling this week with some tasks running in parallel. 

> 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 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....

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 that my pull requests are not breaking/messing the code. 

> so if i understand you correctly, you already have something 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? 

> 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

So, do you think that we can start working like as you said before (fork and pull-requests)?

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 that out. 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 sde95 appears 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 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...

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 < <mailto:>> 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 know is that sent on this public mailing and my own research (your paper from doi 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/> for bmv2
>     - 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/> 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>,
>     - sr-te 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>
>     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 java forwarder, hint here how nsh/mpls done:
>     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
>