Re: [Coin] Fwd: The Future of P4, Revisited

[Haoyu Song <[e-mail]>]

I think it's for a software solution where the data plane and control plane processes run together to mimic the table read and write.
I'm curious to see what's the P4 code look like given the standard doesn't have a direct dataplane write interface to a table, and how it's compare to C code or pseudo code. For example, to describe the behavior of MAC learning, two lines of pseudo code are enough. What the P4 code would look like?
While it's easy to add a write interface to a table for P4 (and update P4 spec to support the programming), it can't be compiled to hardware-based dataplane yet.  Here we are talking about using P4 as a specification/description language. While P4 apps need to be tied with a specific architecture (PISA or PNA), it's difficult to use it as a general and concise language free of any assumptions.

Haoyu

From: Hesham ElBakoury <[e-mail]>
Sent: Thursday, May 18, 2023 11:29 AM
To: Haoyu Song <[e-mail]>
Cc: [e-mail]; Toerless Eckert <[e-mail]>; hemant=[e-mail]; Bernier, Daniel <[e-mail]>; Marie-Jose Montpetit <[e-mail]>; coin <[e-mail]>; coinrg-chairs <[e-mail]>
Subject: Re: [Coin] Fwd: The Future of P4, Revisited

Hi Haoyu,

As I mentioned in my previous email PNA allows writable tables. Please refer to this paper "High-Performance Match-Action Table Updates from within Programmable Software Data Planes" [https://www.google.com/url?sa=t&source=web&rct=j&url=https://www.net.in.tum.de/fileadmin/bibtex/publications/papers/2021-p4-writable-tables.pdf&ved=2ahUKEwja7vydvv_-AhUyO0QIHdXjCxkQFnoECA8QAQ&usg=AOvVaw2le_zu-LXBEDCeFJbs7GZ6]

Thanks
Hesham

On Thu, May 18, 2023, 10:56 AM Haoyu Song <[e-mail]<mailto:[e-mail]>> wrote:
Hi Hesham,

Please see P4 spec section 6.5.2 for the current "stateful" support. So far the "table" element, which is the most important construct for a P4 program,  is not stateful (i.e., dataplane writable)
I think it's a direction to extend P4 for better stateful support (part of my recent research). At least now it's unnatural and difficult to describe many stateful functions.

Haoyu

From: Coin <[e-mail]<mailto:[e-mail]>> On Behalf Of Hesham ElBakoury
Sent: Thursday, May 18, 2023 10:42 AM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Toerless Eckert <[e-mail]<mailto:[e-mail]>>; hemant=[e-mail]<mailto:[e-mail]>; Bernier, Daniel <[e-mail]<mailto:[e-mail]>>; Marie-Jose Montpetit <[e-mail]<mailto:[e-mail]>>; coin <[e-mail]<mailto:[e-mail]>>; coinrg-chairs <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Coin] Fwd: The Future of P4, Revisited

Hi Haoyu,
Actually, P4 supports dataplane-modifiable tables -- see PNA.

More generally, the *language* is fully extensible. You can have whatever architecture and state externs you want. So one needs to be careful to separate language (non) limitations from target limitations.

Hesham

On Thu, May 18, 2023, 10:15 AM Haoyu Song <[e-mail]<mailto:[e-mail]>> wrote:
Hi Hesham,

I said "it's very limited". P4 table is only readable (i.e., not writable) by dataplane, so it basically eliminates any dataplane stateful function that need to use tables. The stateful function can only use register arrays but unfortunately registers are local to a pipeline stage so the state update logic must be very simple and can be finish in a single stage. What you said "event" must be something very simple. Use case such as stateful load balancer can't be implemented by P4.

There are some works addressing the issue. FlowBlaze is the most recent one, which needs a new chip architecture but it is still limited to simple stateful functions which can be realized in a single pipeline stage.

Haoyu

From: Hesham ElBakoury <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, May 18, 2023 10:00 AM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Toerless Eckert <[e-mail]<mailto:[e-mail]>>; hemant=[e-mail]<mailto:[e-mail]>; Bernier, Daniel <[e-mail]<mailto:[e-mail]>>; Marie-Jose Montpetit <[e-mail]<mailto:[e-mail]>>; coin <[e-mail]<mailto:[e-mail]>>; coinrg-chairs <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Coin] Fwd: The Future of P4, Revisited

Hi Haoyu,
You say: "P4 has very limited support for stateful processing"

I am not sure I can agree with your characterization of P4. Perhaps can you elaborate on this.

Thanks
Hesham

On Thu, May 18, 2023, 9:19 AM Haoyu Song <[e-mail]<mailto:[e-mail]>> wrote:
Interesting discussion. See my comments below  [HS]

Haoyu

> For example, in the multicast drafts i write, we use C-pseudocode
> to specify behavior, but we do attempt to implemnt on Tofino in P4. Should we really
> use P4 code for the RFC specs... ? (much longer than C Pseudocode). Aka: quite selfish
> (but IETF relevant ;-) reason to highlight this point.

[EH]: This is an area I'm very interested in. Having a standardized and formal language to describe protocols and behavior can bring a lot of functionality and benefits to the IETF.
My initial thinking is that having such a blueprint, the IETF could generate tools to create a reference implementation that can be used for interoperability purposes therefore decreasing time to test and implement protocols and therefore RFC publications.

[HS] P4 can only describe dataplane behaviors, so any control plane stuff is out of scope. For dataplane, if it's used to describe header format, it's not better than the "struct" in C. The language uses the match-action table abstraction with an implication of pipeline implementation which may make it cumbersome or even impossible to describe the  behavior (e.g.,  P4 has very limited support for stateful processing). In general, I don't think P4 at its current form can undertake the role for formal protocol specification.