[P4-dev] control-plane API generation

Antonin Bas antonin at barefootnetworks.com
Tue Sep 11 10:48:06 EDT 2018


I actually would like to pride myself on having made the code modular so
that new architectures can be supported.
Action parameters are not architecture-specific though, and they are
therefore not handled by the P4RuntimeArchHandlerIface implementation but
are handled in a common fashion: https://github.com/p4lang/p4c/blob/master/
control-plane/p4RuntimeSerializer.cpp#L730
The problem is that you are not talking about supporting P4Runtime for a
new architecture, you are talking about supporting a different version of
P4Runtime, and for that you will need a fork of the p4runtime repository as
well because you need to change the P4Runtime protobuf definitions.

On Tue, Sep 11, 2018 at 6:32 AM, <hemant at mnkcg.com> wrote:

> I agree, forking compiler is not a good option.
>
>
>
> While we are on the subject of P4Runtime and forking compiler, I’d like to
> raise another issue with 1.0 P4Runtime p4c code.  P4Runtime 1.0 does not
> support P4 complex types as parameter to an action.   I wanted to change
> P4Runtime to support a struct as parameter to the action since the number
> of parameters can be large.  Looking at p4c P4Runtime code, I see the code
> is not modular to allow a change.   See below.
>
>
>
> “p4RuntimeArchStandard.cpp implements the common, the v1, and the PSA
> models.   I suppose, I would create a p4RuntimeArchExt.cpp to add an
> implementation of p4RuntimeArchHandler allowing struct as parameter to
> action.  However, how does the new .cpp file get the code from
> p4RuntimeArchStandard.cpp between lines 44-341?  I think the code should be
> common to the extended model, right?  Or should I go ahead and duplicate
> code in p4RuntimeArchEBPF.cpp replacing “namespace Standard {“ with
> “namespace Extended {“?  I think, if we can resolve this issue, I can get
> started on implementation of P4RuntimeArchHandlerIface.”
>
> Since the code is not modular, I was asked to create a fork for my work –
> for short-term, it’s fine.   Eventually, we should make the code modular.
>
>
>
> Thanks,
>
>
>
> Hemant
>
>
>
> *From:* Calin Cascaval <cascaval at barefootnetworks.com>
> *Sent:* Tuesday, September 11, 2018 1:42 AM
> *To:* Mihai Budiu <mbudiu at vmware.com>
> *Cc:* hemant at mnkcg.com; Antonin Bas <antonin at barefootnetworks.com>;
> p4-dev <p4-dev at lists.p4.org>
>
> *Subject:* Re: [P4-dev] control-plane API generation
>
>
>
> Forking the compiler is not ideal since it will be hard to get back
> contributions from other developers. I would rather make an effort to agree
> on where these APIs should be generated in a uniform manner across all
> backends. As Antonin explained, the current point has been agreed upon
> after quite a bit of discussion and I haven't yet seen an instance where
> the point needs to be moved.
>
>
> --
>
> Thanks, Calin
>
>
>
> On Sep 10, 2018, at 22:31, Mihai Budiu <mbudiu at vmware.com> wrote:
>
>
>
> The compiler is open-source and nothing prevents you from forking it and
> moving the API generation to another place. Of course, then you will have
> to keep the fork updated, which is not easy long term. It is a good idea to
> have the API match the program that the user wrote, and not a transformed
> version of that program. If the API matches a modified program then you
> have to write down the rules by which the program is modified so people
> will know how to implement the API. It is much simpler to have no special
> rules whatsoever.
>
>
>
> Mihai
>
>
>
> *From:* P4-dev <p4-dev-bounces at lists.p4.org> *On Behalf Of *
> hemant at mnkcg.com
> *Sent:* Monday, September 10, 2018 7:55 AM
> *To:* 'Antonin Bas' <antonin at barefootnetworks.com>
> *Cc:* 'p4-dev' <p4-dev at lists.p4.org>
> *Subject:* Re: [P4-dev] control-plane API generation
>
>
>
> Got it.  At the June 2018 P4 Workshop, in the Mellanox P4 to SAI demo, I
> asked where is the SAI API generated from in p4c?  I thought I heard, “by
> the midend”.   Since SAI is also independent of any asic, SAI API
> generation should also be invoked after the frontend.  Maybe, someone from
> Mellanox can confirm since I don’t see details in their slide nor the
> abstract.  I would like to what, if SAI API generation is done after the
> frontend processing, before any midend processing is run?
>
>
>
> Thanks,
>
>
>
> Hemant
>
>
>
> *From:* Antonin Bas <antonin at barefootnetworks.com>
> *Sent:* Monday, September 10, 2018 10:09 AM
> *To:* hemant at mnkcg.com
> *Cc:* p4-dev <p4-dev at lists.p4.org>
> *Subject:* Re: [P4-dev] control-plane API generation
>
>
>
> This is a hard rule as far as I'm concerned. We actually worked hard to
> ensure that API generation happens right after the frontend and does not
> depend on the backend (or the midend passes that this backend chooses to
> use). The generated P4Info message should be exactly the same independently
> of which backend you are using.
>
> What we can do though is invoke midend passes independently of the backend
> in the P4Info generation code (https://github.com/p4lang/
> p4c/blob/master/control-plane/p4RuntimeSerializer.cpp#L1328
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fp4lang%2Fp4c%2Fblob%2Fmaster%2Fcontrol-plane%2Fp4RuntimeSerializer.cpp%23L1328&data=02%7C01%7Cmbudiu%40vmware.com%7C5ab3733f89a649fec26708d6172d7b68%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636721881452912410&sdata=meH7Awo664afSVN1McTSDVfATNmhyTVEJjISdRVdzIE%3D&reserved=0>
> ). I believe that usually it is best avoided: you want the P4Info message
> / the runtime APIs to match exactly the contents of the P4 program.
>
>
>
> On Wed, Sep 5, 2018 at 1:33 PM, <hemant at mnkcg.com> wrote:
>
> In the bmv2 backend, I see that P4Runtime/control-plane API generation is
> called in p4c/backends/bmv2/simple_switch/main.cpp after
> frontend.run().   Is this a hard rule or can one move the API generation,
> for example, to be after midend.process()?
>
>
>
> Thanks in advance.
>
>
>
> Hemant
>
>
>
> MNK Consulting
>
> http://mnkcg.com
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmnkcg.com%2F&data=02%7C01%7Cmbudiu%40vmware.com%7C5ab3733f89a649fec26708d6172d7b68%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636721881452912410&sdata=RvUdw1DK5qtQm2m1cWad1fPTKpxHLV6Q3nqcVdRPPZY%3D&reserved=0>
>
>
>
>
> _______________________________________________
> P4-dev mailing list
> P4-dev at lists.p4.org
> http://lists.p4.org/mailman/listinfo/p4-dev_lists.p4.org
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.p4.org%2Fmailman%2Flistinfo%2Fp4-dev_lists.p4.org&data=02%7C01%7Cmbudiu%40vmware.com%7C5ab3733f89a649fec26708d6172d7b68%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636721881452912410&sdata=Q6sYpB6TxgooC31FRkVMwCrd%2BL8IMba1FHAvVolRXRc%3D&reserved=0>
>
>
>
>
>
> --
>
> Antonin
>
> _______________________________________________
> P4-dev mailing list
> P4-dev at lists.p4.org
> http://lists.p4.org/mailman/listinfo/p4-dev_lists.p4.org
>
>
>



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


More information about the P4-dev mailing list