[P4-dev] control-plane API generation

hemant at mnkcg.com hemant at mnkcg.com
Tue Sep 11 09:32:26 EDT 2018


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 <mailto: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 < <mailto:p4-dev-bounces at lists.p4.org> p4-dev-bounces at lists.p4.org> On Behalf Of  <mailto:hemant at mnkcg.com> hemant at mnkcg.com
Sent: Monday, September 10, 2018 7:55 AM
To: 'Antonin Bas' < <mailto:antonin at barefootnetworks.com> antonin at barefootnetworks.com>
Cc: 'p4-dev' < <mailto:p4-dev at lists.p4.org> 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 < <mailto:antonin at barefootnetworks.com> antonin at barefootnetworks.com> 
Sent: Monday, September 10, 2018 10:09 AM
To:  <mailto:hemant at mnkcg.com> hemant at mnkcg.com
Cc: p4-dev < <mailto:p4-dev at lists.p4.org> 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://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> https://github.com/p4lang/p4c/blob/master/control-plane/p4RuntimeSerializer.cpp#L1328). 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, < <mailto:hemant at mnkcg.com> 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

 <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> http://mnkcg.com

 


_______________________________________________
P4-dev mailing list
 <mailto:P4-dev at lists.p4.org> P4-dev at 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> http://lists.p4.org/mailman/listinfo/p4-dev_lists.p4.org





 

-- 

Antonin

_______________________________________________
P4-dev mailing list
 <mailto:P4-dev at lists.p4.org> P4-dev at lists.p4.org
 <http://lists.p4.org/mailman/listinfo/p4-dev_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/20180911/3bc21897/attachment-0001.html>


More information about the P4-dev mailing list