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

[Hesham ElBakoury <[e-mail]>]

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]> 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]> *On Behalf Of * Hesham ElBakoury
> *Sent:* Thursday, May 18, 2023 10:42 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,
>
> 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]>
> 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]>
> *Sent:* Thursday, May 18, 2023 10:00 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,
>
> 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]> 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.
>
>