[P4-dev] p4lang/third-party

Frédéric LOUI frederic.loui at renater.fr
Fri Feb 22 15:01:13 EST 2019


Salut Antonin,

Merci pour ta réponse plutôt positive. 
My answers inline :)

> I think it's a great idea to build Debian packages for the p4lang software

Well, I’m working for RENATER (French Education & Research Network) and within the scope of our project learning/dissemination is part of our role.
I hoping these packages will help propagate p4 programming.

> especially if the packages end up in the official distribution repositories and especially if your organization is volunteering to maintain them :) 

Well for now, we just want to appreciate, if these packages will be useful and build a first set that fit the potential training we might conduct ourselves.
We have a p4 event during next TNC: https://tnc19.geant.org/ <https://tnc19.geant.org/> (Where all academic networks in Europe get together) 
As we are working in a academic model we can possibly but this is not granted have resources meant to maintain these packages if they are used by our organisation. :)

> currently the most used p4lang repositories are p4c, bmv2 and PI AFAIK … 
> so you should focus on these

We will. However we are working actively on identifying how to « hook » our control plane to switch.p4 (for example) using gRPC. 

> - a lot of the dependencies are actually optional. For example, the tutorials use the bmv2 simple_switch target, which does not require Thrift. So a bmv2 Debian package without Thrift support would still be very useful. Similarly sysrepo is optional - used to run a gNMI service in simple_switch_grpc - and I would omit it at first. That applies to libyang as well, since it is only used by sysrepo. Nanomsg is also optional and is used to run the bmv2 debugger (p4dbg.py), but it seems that there is a package available in your Debian distribution so maybe it is not too much trouble (except for nnpy).

So PI (P4runtime implementation is also a must for us) and simple_switch_grpc

> - speaking as the maintainer for bmv2 & PI, I am open to modifications to the code to get it working with more recent versions of the dependencies (protobuf, grpc, nanomsg, ...), as long as the code still works with the older versions references in p4lang/third-party. Ideally support for more recent versions of the libraries would be tested in CI, but that may be too much to ask and the testing matrix may become too complex.

For now I propose to have a first set of packages that fit existing code and principle. 
Maybe code modification is needed in order to support recent dependencies and fit automatic package generation, in that case we will propose this to you. 
But only if you agree and if it serves your purpose.

>  Ideally support for more recent versions of the libraries would be tested in CI, but that may be too much to ask and the testing matrix may become too complex.

If CI chain is elaborated it should be OK.

> but that may be too much to ask and the testing matrix may become too complex.
Well, we have some experts within EU organisation whose job is to implement these CI chains.

> - I also welcome changes to the Python scripts to make them work with python 3, as long as backward-compatibility with Python 2.7 is not broken

Noted.

> (As a remainder, your organization needs to be a p4.org <http://p4.org/> member in order for you to contribute code to p4lang)
Our project started in January 2019 (M1 and should last 24 months). If fruitful it is not sure but it can be reconnected during 24 months again.
I think GEANT/NRENs can become p4.org <http://p4.org/> member during this period.

> Please let me know if you have questions.
OK ! Thank you for your support and valuable answer.

We will keep you posted regarding our progress.

Merci & Bon week end,

À bientôt,
--  Frederic




> Le 22 févr. 2019 à 20:17, Antonin Bas <antonin at barefootnetworks.com> a écrit :
> 
> Salut Frederic,
> 
> I think it's a great idea to build Debian packages for the p4lang software, especially if the packages end up in the official distribution repositories and especially if your organization is volunteering to maintain them :) I'm a Ubuntu user myself so obviously I'm more biased towards that distribution.
> Some information that may be useful:
> - currently the most used p4lang repositories are p4c, bmv2 and PI AFAIK. These projects are used in particular for the P4 tutorials (orchestrated by p4app and run inside a Docker image), so you should focus on these
> - a lot of the dependencies are actually optional. For example, the tutorials use the bmv2 simple_switch target, which does not require Thrift. So a bmv2 Debian package without Thrift support would still be very useful. Similarly sysrepo is optional - used to run a gNMI service in simple_switch_grpc - and I would omit it at first. That applies to libyang as well, since it is only used by sysrepo. Nanomsg is also optional and is used to run the bmv2 debugger (p4dbg.py), but it seems that there is a package available in your Debian distribution so maybe it is not too much trouble (except for nnpy).
> - speaking as the maintainer for bmv2 & PI, I am open to modifications to the code to get it working with more recent versions of the dependencies (protobuf, grpc, nanomsg, ...), as long as the code still works with the older versions references in p4lang/third-party. Ideally support for more recent versions of the libraries would be tested in CI, but that may be too much to ask and the testing matrix may become too complex.
> - I also welcome changes to the Python scripts to make them work with python 3, as long as backward-compatibility with Python 2.7 is not broken
> 
> (As a remainder, your organization needs to be a p4.org <http://p4.org/> member in order for you to contribute code to p4lang)
> 
> Please let me know if you have questions.
> 
> Antonin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20190222/98c93f5a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3592 bytes
Desc: not available
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20190222/98c93f5a/attachment-0001.p7s>


More information about the P4-dev mailing list