<p dir="ltr"></p>
<p dir="ltr">Sony Xperia™ okostelefonomról küldve</p>
<br><br>---- Eredeti üzenet ----<br>Tárgy: [P4-announce] P4 evolution roadmap<br>Küldve: 2016.01.08. 7:33<br>Feladó: Changhoon Kim <chang@barefootnetworks.com><br>Címzett: p4-announce@p4.org,p4-dev@p4.org,p4-discuss@p4.org<br>Másolatot kap: p4-design@p4.org<br><br><div dir="ltr"><div style="font-size:12.8px">Hi P4 enthusiasts,</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Happy new year!</div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px"><span style="font-size:12.8px">Since the last workshop many people asked me to share some rough outlines for the next steps for P4. Some of us, including the board members of the consortium and the p4-design working group members, have been corresponding since then, and here's the rough roadmap we're proposing.</span></div><ul style="font-size:12.8px"><li style="margin-left:15px">Next P4 spec revision (post v1.1)</li><ul><li style="margin-left:15px"><a href="http://p4.org/wp-content/uploads/2015/11/p4-v1.1rc-Nov-17.pdf">The latest P4 spec</a> (v1.1rc) offers a decent set of features. I believe we can safely expect to see in the coming months several P4 programmable targets and a bunch of P4 programs written in v1.1. Once such initial development work is done, P4 users and target providers will soon desire capabilities to reuse their code -- either their P4 code itself or their code for the P4 development tools (compiler front-end, etc.) -- as much as possible over various types and generations of P4 targets. Achieving such a goal will essentially hinge on language constructs that can enable architecture-language separation, portability, and composability. Hence, designing and implementing those new language constructs will be the paramount focus of the next language revision. I've presented the case for all these in <a href="http://schd.ws/hosted_files/2ndp4workshop2015/33/Chang,%20P4%20Workshop%20Nov%2018%202015.pdf">my P4 status update at the last workshop</a>.</li><li style="margin-left:15px">In terms of timeline for the next revision, I'd suggest we take enough time to design and build a mature, well-designed, and well-tested feature set. Hence I'd suggest we target the delivery of the next language spec for the second half of CY 2016, but no earlier that that. Hopefully doing so will allow P4 users to digest what they have now and thus build enough momentum around v1.1. Starting with the next version, we should address the issue of backwards compatibility by offering forward conversion-assistance tools -- s/w that can convert a v1.1 code to the next version. </li></ul></ul><ul style="font-size:12.8px"><li style="margin-left:15px">Sub-groups for a few high-priority work items</li><ul><li style="margin-left:15px">As some of us mentioned at the workshop, the following areas seem to deserve dedicated sub-group activities. #1 is what we've been already doing in p4-design, and #2 and #3 are new ones. </li><ul><li style="margin-left:15px">1. Language and Standard library</li><li style="margin-left:15px">2. Standard Architecture</li><li style="margin-left:15px">3. API Generation Convention</li></ul><li style="margin-left:15px">Going forward, we might need to consider introducing a couple more sub-groups if there's a justifiable amount of work. The following areas seem to be where further work could be necessary, though the tools work might as well just continue as part of the open-source projects within the charter of the other sub-groups.</li><ul><li style="margin-left:15px">Compliance</li><li style="margin-left:15px">Use cases (P4 applications)</li><li style="margin-left:15px">Tool chains (e.g., IR connecting between compiler front-end and back-ends)</li></ul><li style="margin-left:15px">In terms of the timeline and logistics, the language sub-group will first need to agree on the direction of the architecture-language separation proposal so that it can offer seeds for the Standard Architecture sub-group's activities. I'd expect the Language sub-group would be able to reach such a consensus by sometime in Q1 2016, no later than March. Once that's done, we'll be able to officially kick off the Standard Architecture sub-group soon after. On the other hand, the scope of the API sub-group seems to be loosely related to the others, and hence they'll probably be able to start a bit early, say in Feb. As mentioned, each sub-group will set its own schedules and logistics for meetings and collaboration. Given the diversity in geo-locations of the active P4 members, each group should definitely employ some means of teleconference. </li><li style="margin-left:15px">Of course these sub-groups should work very tightly together because their deliverables are inter-dependent to one another's. Thus, we'll have regular plenary meetings, perhaps once every or every other month and preferably in-person.</li><li style="margin-left:15px">In addition to the sub-groups above, it m<span style="font-size:12.8px">ight be good to have a small named Language Advisory Group (</span><span style="font-size:12.8px">LAG</span><span style="font-size:12.8px">) for P4. The members of the group will not necessarily be responsible for delivering the specifications of the language or associated tools, but are recognized thought leaders to provide sage input to the working groups in P4.org. We've reached out a few experts in academia and research labs to see who are interested in this. David Walker (Princeton), Nate Foster (Cornell), Mihai Budiu (Barefoot Networks), Nikolaj Bjorner (Microsoft Research), and Arjun Guha (UMass) have agreed to join the advisory group -- thanks! -- and we might invite one or two more experts going forward.</span></li></ul><ul></ul></ul><ul style="font-size:12.8px"><li style="margin-left:15px">More open source</li><ul><li style="margin-left:15px">At the end of the day, P4.org is an open-source consortium, and hence "code is king". We'll firmly stick with this guideline and recommend each sub-group focus on delivering quality running code as the top priority, rather than just specs. This means the sub-groups will be responsible for producing the following specific code (and perhaps more) based on the schedules they'll set.</li><ul><li style="margin-left:15px">Language and Standard Library group</li><ul><li style="margin-left:15px">Reference P4 compiler frontend</li><li style="margin-left:15px">Reference P4 compiler backend for a few targets including the S/W P4 switch, dependency analyzer, etc.</li><li style="margin-left:15px">A S/W P4 switch</li><li style="margin-left:15px">Reference C-implementation (or Python implementation) of the Standard Library (extern types and primitive actions)</li><li style="margin-left:15px">Test P4 programs and suites attesting compliance to the Standard Library</li></ul><li style="margin-left:15px">Architecture group</li><ul><li style="margin-left:15px">S/W P4 switch realizing the Standard Architecture</li><li style="margin-left:15px">Test P4 programs and suites attesting compliance to the Standard Architecture</li></ul><li style="margin-left:15px">API generation convention</li><ul><li style="margin-left:15px">API generation tools (part of the compiler front-end)</li></ul></ul></ul></ul><div style="font-size:12.8px">Hope this clarifies what P4.org is going to work on and how over the next several quarters. I'm corresponding with a few folks who expressed their interest in leading the sub-group activities and will soon release our initial plan for that, hopefully in a week or two from now. </div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Please feel free to share suggestions or ask questions.<br></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Thanks.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">-- Chang</div></div>