[P4-dev] p4lang/third-party

Andy Fingerhut andy.fingerhut at gmail.com
Fri Feb 22 18:16:52 EST 2019


Note that it fails with Ubuntu 18.04 Linux without patches to gRPC.  It
works perfectly fine unpatched on Ubuntu 16.04 Linux, which is still the
recommended base OS, I believe.  I'm sure that will update to a later
version of Linux some time, but probably for most the goal is not to be on
the bleeding edge for libraries on which P4 tools depend (yes, I know we
are far from the bleeding edge on versions there).

Andy

On Fri, Feb 22, 2019 at 1:50 PM <hemant at mnkcg.com> wrote:

> At some point, we do have to update the gRPC version used by PI because
> the version does not build.  See https://github.com/p4lang/PI/issues/436
>
> Andy has a script to install PI and the script applies patches to gRPC.
> If one has only downloaded PI and gRPC separately, then, I have code
> changes shown in the issue above for how to fix the build.
>
>
>
> Hemant
>
>
>
> *From:* P4-dev <p4-dev-bounces at lists.p4.org> *On Behalf Of *Frédéric LOUI
> *Sent:* Friday, February 22, 2019 3:01 PM
> *To:* Antonin Bas <antonin at barefootnetworks.com>
> *Cc:* p4-dev <p4-dev at lists.p4.org>
> *Subject:* Re: [P4-dev] p4lang/third-party
>
>
>
> 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/ (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 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 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 member in order
> for you to contribute code to p4lang)
>
>
>
> Please let me know if you have questions.
>
>
>
> Antonin
>
>
> _______________________________________________
> P4-dev mailing list
> P4-dev at lists.p4.org
> http://lists.p4.org/mailman/listinfo/p4-dev_lists.p4.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20190222/730f87b5/attachment-0001.html>


More information about the P4-dev mailing list