[P4-dev] p4lang/third-party

hemant at mnkcg.com hemant at mnkcg.com
Fri Feb 22 12:33:39 EST 2019


First, this is the right mailer.  

Second, p4c uses python 2.7 and won’t work with python3.

 

I would just use Andy’s script to install p4c and behavioral-model with all dependencies needed – the script installs all software from scratch.   Debian should not have a problem.

https://github.com/jafingerhut/p4-guide/blob/master/bin/install-p4dev.sh - install p4c, behavioral-model, and the software they depend upon. No P4Runtime code installed

It is better to get going with the script rather than micro-managing different versions of the dependent software.

 

Good luck,

 

Hemant

 

 

From: P4-dev <p4-dev-bounces at lists.p4.org> On Behalf Of Frédéric LOUI
Sent: Friday, February 22, 2019 11:11 AM
To: p4-dev at lists.p4.org
Subject: [P4-dev] p4lang/third-party

 

 

Hi experts,

 

We are working on a R&E project that will involve (among various objectives) p4 Software Development Environment set up using p4lang project tools. 

(p4c, bmv2 etc.) We started to work on some packages and therefore we have some questions. 

We might have more questions so let me know if I’m on the right mailing list. :-)

 

In our building process, we followed p4app approach.

 

In that purpose we started to analyse the various Dockerfile and landed in the 3rd party folder here: 

https://github.com/p4lang/third-party 

 

Assumptions:

1- For now our target is Debian buster, we will for sure adapt the process for ubuntu is this is not too complex.

2- Long term goal: If successful and satisfying enough, we might ask Debian project to add these packages into the mainstream tree. 

3- As a first steps, let’s focus only on the 3rd party repository. Building BMv2 targets and p4c will then be easier.

 

Here is the list of dependancies listed in 3rd party docker file : (and what we have done so far)

 

* cchache 

  Need: accelerate compilation duration by caching operations

  p4lang: it uses 3.3

  Buster: cache 3.6-1

  We plan to use buster 3.6-1 which is ( > 3.3 )

  It uses memcached

  -> so what can be done is using existing buster source deb and rebuild a packet with memcached trigger (not essential but TO BE DONE)

 

* scapy 

   Need: used by ptf

   p4lang: it uses v2.2.0-dev and modified version made by BAREFOOT 

   Buster: v2.4.0

   Last version of scapy have improved header (MPLS for example)

  -> we plan to reuse Buster 2.4.0 package and reuse it to build 2.4.2 as a base (—> DONE)

 

* PTF

   p4lang: It is a p4lang project 

   Need: need scapy with additional header

   Buster: <no package>

   -> we plan build ptf package  (—> DONE)

   One remark I had from one of our openSource expert is to port ptf to python3 (it refused to be installed using python3)

   It was mentioned that python 2.7 support end end of 2020.

 

* nanomsg

   p4lang: It uses v1.1.0 (SOVERSION is 5.0.0)

   Buster: 1.1.5

  —> we plan to use nanomsg from the official BUSTER repository (-> DONE)

 

* nnpy

   p4lang: It uses an old RC version (tree 096998834451219ee7813d8977f6a4027b0ccb43) 

   Buster: <no package>

   -> we plan build nnpy 1.4.2 package  (—> TO BE DONE)

 

* thrift 

   p4lang: It uses v0.9.2

   Buster: v0.11.0

   -> we plan to use the official version in Buster: v0.11.0 (TO BE DONE)

 

* protobuf

   p4lang:  v3.2.0

   Buster: v3.6.1

   -> we plan to use the official version in Buster: v3.6.1 (TO BE DONE)

 

* protobuf-c 

   p4lang:  v3.2.0

   Buster: v3.6.1

   -> we plan to use the official version in Buster: v3.6.1 (TO BE DONE)

 

 

* python-protobuf

   p4lang:v3.2.0

   Buster: v3.6.1

   -> we plan to use the official version in Buster: v3.6.1 (TO BE DONE)

 

 

* grpc

  p4lang:  v1.3.2

  Buster: v1.6.4 (not sure here)

   -> we plan to use the official version in Buster: v1.6.4 (not sure here) (TO BE DONE)

 

* libyang

  p4lang: v0.16-r1

  Buster: 0.16.105-1 

   -> we plan to use the official version in Buster: 0.16.105-1

 

* sysrepo

  p4lang: v0.7.5

  Buster: <no package>

  -> we plan build ptf package  (—> TO BE DONE DONE)

 

The questions are:

 

- Do you think we can use the distro (here BUSTER) package ? 

For sysrepo/nnpy packages have to be built. The tricky packages are the one depending on openssl and related to graph and thrift.

According to your experience what is your feedback regarding compilation against these dependencies ? Is it something set on stone ?

 

In order to move forward, we plan to build p4lang containers using as much as possible the package above (so also the package we built )

in order to validate them.

 

PS1: Once built we will of course contribute back to p4lang and if it make sense provide additional support for other Debian like OS.

       We started weith BUSTER because our expert who is helping us is an exclusive debian BUSTER. 

       Also it gives us an understanding of the whole p4lang suite dependancies.

 

PS2: I would like to thank Andy Fingerhut and Edgar Costa for they repository. I learned a lot from them.

 

Thanks in advance for your help then :)

 

All the best,

 

Have a good week end & "À bientôt",

--  Frederic

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20190222/de5723c2/attachment.html>


More information about the P4-dev mailing list