Re: new language features for "5G" and "edge" use cases

MB
Mihai Budiu
Fri, Jun 11, 2021 10:56 PM

Indeed, this should work.
It currently does not, so I filed an issue: https://github.com/p4lang/p4c/issues/2795
Hopefully this (and support in your favorite back-end) is everything that is needed.
If not, we’ll file more issues.

Mihai

From: Gurevich, Vladimir vladimir.gurevich@intel.com
Sent: Thursday, June 10, 2021 11:55 AM
To: Mihai Budiu mbudiu@vmware.com; Gergely Pongracz Gergely.Pongracz@ericsson.com; hemant@mnkcg.com; jnfoster@cs.cornell.edu
Cc: p4-design@lists.p4.org
Subject: Re: [P4-design] Re: new language features for "5G" and "edge" use cases

Hello Mihai,

So far, I am a little hesitant to allow pkt.emit() for the scalar types, mostly because I do not have a good proposal on how to handle non-byte-aligned ones.

I wonder, whether a construct like:

   pkt.emit((bridge_t){f1, f2});

will do the job of an unconditional emit, since we are effectively creating a valid header on the spot, so the compiler will be free to optimize the validity check out. At the same time, the byte alignment requirement can still be enforced.

Thanks,
Vladimir Gurevich
Principal Engineer,  Barefoot Division (BXD)https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fintel.com%2Fprogrammable-networking&data=04%7C01%7Cmbudiu%40vmware.com%7Ccaaead125a664bdb711008d92c4138df%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637589480923395539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UsE5phakl2ecAsSkh0BAZUU7fTAuQpwpzKrNOChcph8%3D&reserved=0
Director, Intel® Connectivity Education Hubhttps://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fintel.com%2Fconnectivity-education&data=04%7C01%7Cmbudiu%40vmware.com%7Ccaaead125a664bdb711008d92c4138df%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637589480923405640%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GGyNepNxDOPuAIhm5OOZ7NSCmjeZR1GRbvFxa80y%2Bs8%3D&reserved=0

Email:      Vladimir.Gurevich@intel.commailto:Vladimir.Gurevich@intel.com
Cell:        +1 (408) 833-4505
[A close up of a sign  Description automatically generated]https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fintel.com%2F&data=04%7C01%7Cmbudiu%40vmware.com%7Ccaaead125a664bdb711008d92c4138df%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637589480923405640%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4qZX%2Byz4l8ygWgxNtp0q0hD1hB4hVGHNc5cnFDlkxCc%3D&reserved=0

From: Mihai Budiu <mbudiu@vmware.commailto:mbudiu@vmware.com>
Date: Monday, June 7, 2021 at 8:55 PM
To: "Gurevich, Vladimir" <vladimir.gurevich@intel.commailto:vladimir.gurevich@intel.com>, Gergely Pongracz <Gergely.Pongracz@ericsson.commailto:Gergely.Pongracz@ericsson.com>, "hemant@mnkcg.commailto:hemant@mnkcg.com" <hemant@mnkcg.commailto:hemant@mnkcg.com>, "jnfoster@cs.cornell.edumailto:jnfoster@cs.cornell.edu" <jnfoster@cs.cornell.edumailto:jnfoster@cs.cornell.edu>
Cc: "p4-design@lists.p4.orgmailto:p4-design@lists.p4.org" <p4-design@lists.p4.orgmailto:p4-design@lists.p4.org>
Subject: RE: [P4-design] Re: new language features for "5G" and "edge" use cases

Section 15.1 of the spec says:

  • It is illegal to invoke emit on an expression whose type is a base type, enum, or error.

If we had emit for base types this could work very well. I see no problem why that would not work.
If that’s what you want you should file an issue with the spec so we can discuss this during the design meeting.
You don’t need a new method, the existing emit should work just fine.

Mihai

From: Gurevich, Vladimir <vladimir.gurevich@intel.commailto:vladimir.gurevich@intel.com>
Sent: Monday, June 7, 2021 6:27 AM
To: Gergely Pongracz <Gergely.Pongracz@ericsson.commailto:Gergely.Pongracz@ericsson.com>; hemant@mnkcg.commailto:hemant@mnkcg.com; Mihai Budiu <mbudiu@vmware.commailto:mbudiu@vmware.com>; jnfoster@cs.cornell.edumailto:jnfoster@cs.cornell.edu
Cc: p4-design@lists.p4.orgmailto:p4-design@lists.p4.org
Subject: Re: [P4-design] Re: new language features for "5G" and "edge" use cases

All,

To be honest, I think that what be more useful is to have an unconditional emit 😊. Aside from the fact that it will, obviously allow us to express the traditional emit as:

pkt.emit(hdr.a) ::=
if (hdr.a.isValid()) {
pkt.unconditional_emit(hdr.a);
}

it would also allow us to be more flexible with other emits and allow us to optimize the programs on certain architectures.

As a practical example, it is quite helpful when someone needs to create a bridge header in PSA, TNA or a similar architecture “on the fly”, e.g:

header bridge_h {
type1_t f1; /* Usually comes from meta.f1 /
type2_t f2; /
Usually comes from meta.f2 */
}

struct my_headers_t {
ethernet_h ethernet;
. . . .
}

control IgressDeparser(
packet_out  pkt,
my_headers_t hdr,
my_meta_t    meta)
{
/* Emit on the fly and there is no need to keep the header validity bit around */
pkt.uncoditional_emit<bridge_h>(meta.f1, meta.f2);
pkt.emit(hdr);
}

Currently we have to make the header  valid and copy the data into it (typically at the end of the control) and while the compiler can optimize many of these assignments and such, it is always better when someone can clearly express the intent.

Again, it is not that a big deal (it is possible to live without this), but I thought it will make the overall design more orthogonal. The name “unconditional_emit()” is certainly not the prettiest one – I put it here for clarity only.

Best,
Vladimir Gurevich
Principal Engineer,  Barefoot Division (BXD)https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fintel.com%2Fprogrammable-networking&data=04%7C01%7Cmbudiu%40vmware.com%7Ccaaead125a664bdb711008d92c4138df%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637589480923405640%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NqImAD3PW5bnW2uXZIOxbGzgeK5rz6i%2FUBosZ4vluvY%3D&reserved=0
Director, Intel® Connectivity Education Hubhttps://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fintel.com%2Fconnectivity-education&data=04%7C01%7Cmbudiu%40vmware.com%7Ccaaead125a664bdb711008d92c4138df%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637589480923415528%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QURa%2BcbNGVuSNs%2Fm42QalrMjdPbn5eiB4h1Vpy%2BUwV4%3D&reserved=0

Email:      Vladimir.Gurevich@intel.commailto:Vladimir.Gurevich@intel.com
Cell:        +1 (408) 833-4505
[A close up of a sign  Description automatically generated]https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fintel.com%2F&data=04%7C01%7Cmbudiu%40vmware.com%7Ccaaead125a664bdb711008d92c4138df%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637589480923425524%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hR7dQNw3HrUM62IAUXsOalWTxR6%2FiPqOtM8uldgR8eI%3D&reserved=0

From: Gergely Pongracz via P4-design <p4-design@lists.p4.orgmailto:p4-design@lists.p4.org>
Reply-To: Gergely Pongracz <Gergely.Pongracz@ericsson.commailto:Gergely.Pongracz@ericsson.com>
Date: Monday, June 7, 2021 at 12:30 PM
To: "hemant@mnkcg.commailto:hemant@mnkcg.com" <hemant@mnkcg.commailto:hemant@mnkcg.com>, "mbudiu@vmware.commailto:mbudiu@vmware.com" <mbudiu@vmware.commailto:mbudiu@vmware.com>, "jnfoster@cs.cornell.edumailto:jnfoster@cs.cornell.edu" <jnfoster@cs.cornell.edumailto:jnfoster@cs.cornell.edu>
Cc: "p4-design@lists.p4.orgmailto:p4-design@lists.p4.org" <p4-design@lists.p4.orgmailto:p4-design@lists.p4.org>
Subject: [P4-design] Re: new language features for "5G" and "edge" use cases

Hi,

Guys, don’t get stuck on this, as I indicated in the paper this is a minor issue, we solved it exactly as Mihai proposed below.
BR,

Gergely

From: hemant@mnkcg.commailto:hemant@mnkcg.com <hemant@mnkcg.commailto:hemant@mnkcg.com>
Sent: Friday, June 4, 2021 10:54 PM
To: mbudiu@vmware.commailto:mbudiu@vmware.com; Gergely Pongracz <Gergely.Pongracz@ericsson.commailto:Gergely.Pongracz@ericsson.com>; jnfoster@cs.cornell.edumailto:jnfoster@cs.cornell.edu
Cc: p4-design@lists.p4.orgmailto:p4-design@lists.p4.org
Subject: RE: [P4-design] Re: new language features for "5G" and "edge" use cases

Mihai,

I was only echoing the ask from Gergely slides.  Indeed, I too have written code such that I used the if-condition in egress control and set a header to invalid.  So, I don’t see a pressing need to use if condition in deparser.

Hemant

From: Mihai Budiu <mbudiu@vmware.commailto:mbudiu@vmware.com>
Sent: Friday, June 04, 2021 4:49 PM
To: hemant@mnkcg.commailto:hemant@mnkcg.com; Gergely.Pongracz@ericsson.commailto:Gergely.Pongracz@ericsson.com; jnfoster@cs.cornell.edumailto:jnfoster@cs.cornell.edu
Subject: RE: [P4-design] Re: new language features for "5G" and "edge" use cases

First, please note that P4 does not limit deparser to just emit statements; a deparser is a general control, and it can certainly have if statements. Only targets (i.e., backends) may limit what the deparser can do. I will submit a PR against the p4c-xdp target to show that this is supported by P4.

Second, for architectures like Tofino, a statement like this in the deparser:

If (condition) packet.emit(h);

Can be rewritten as two statements:

  1. In egress, towards the end:

if (!condition)
h.setInvalid();

  1. And in deparser an unconditional emit:

packet.emit(h);

For a specific architecture we could even make this transformation automatically.

Mihai

From: hemant@mnkcg.commailto:hemant@mnkcg.com <hemant@mnkcg.commailto:hemant@mnkcg.com>
Sent: Friday, June 4, 2021 1:18 PM
To: Mihai Budiu <mbudiu@vmware.commailto:mbudiu@vmware.com>; Gergely.Pongracz@ericsson.commailto:Gergely.Pongracz@ericsson.com; jnfoster@cs.cornell.edumailto:jnfoster@cs.cornell.edu
Subject: RE: [P4-design] Re: new language features for "5G" and "edge" use cases

I understand, an invalid header is not emitted.  However, what if I want an if-condition such as if (bla-bla), then emit a header.

Thanks,

Hemant

From: Mihai Budiu <mbudiu@vmware.commailto:mbudiu@vmware.com>
Sent: Friday, June 04, 2021 4:02 PM
To: hemant@mnkcg.commailto:hemant@mnkcg.com; Gergely.Pongracz@ericsson.commailto:Gergely.Pongracz@ericsson.com; jnfoster@cs.cornell.edumailto:jnfoster@cs.cornell.edu
Subject: RE: [P4-design] Re: new language features for "5G" and "edge" use cases

Why is a conditional emit necessary? Invalid headers are not emitted.

Mihai

From: Hemant Singh via P4-design <p4-design@lists.p4.orgmailto:p4-design@lists.p4.org>
Sent: Friday, June 4, 2021 12:30 PM
To: Gergely.Pongracz@ericsson.commailto:Gergely.Pongracz@ericsson.com; jnfoster@cs.cornell.edumailto:jnfoster@cs.cornell.edu
Cc: p4-design@lists.p4.orgmailto:p4-design@lists.p4.org
Subject: [P4-design] Re: new language features for "5G" and "edge" use cases

If one sees Gergely’s slides (https://opennetworking.org/wp-content/uploads/2021/05/Gergely-Pongracz-Slides.pdfhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D1624152c-49bf2c29-162455b7-86959e472243-22c1e57e660a62c9%26q%3D1%26e%3Dc06da983-d08b-4708-b883-00e45e68f49a%26u%3Dhttps%253A%252F%252Fnam04.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fopennetworking.org%25252Fwp-content%25252Fuploads%25252F2021%25252F05%25252FGergely-Pongracz-Slides.pdf%2526data%253D04%25257C01%25257Cmbudiu%252540vmware.com%25257Cce1277d5b5274442bcc508d9278f1647%25257Cb39138ca3cee4b4aa4d6cd83d9dd62f0%25257C0%25257C1%25257C637584317782230493%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253DVzYSSFY3cpIbHogO%25252Fy1ovMCwdxkxwQi%25252FA%25252FA%25252BcSvLoY0%25253D%2526reserved%253D0&data=04%7C01%7Cmbudiu%40vmware.com%7Ccaaead125a664bdb711008d92c4138df%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637589480923425524%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8O4yKPcbV1GDvzjgpEidtrRrKIf7p9vpJgsMBnrI09Q%3D&reserved=0), he has also asked for conditional emit in deparser.  p4c has already added an if condition to the P4 parser during this year.  We should discuss use of conditional in deparser, at least for certain low speed architectures.

Thanks,

Hemant

From: Gergely Pongracz via P4-design <p4-design@lists.p4.orgmailto:p4-design@lists.p4.org>
Sent: Friday, June 04, 2021 5:14 AM
To: Nate Foster <jnfoster@cs.cornell.edumailto:jnfoster@cs.cornell.edu>
Cc: p4-design <p4-design@lists.p4.orgmailto:p4-design@lists.p4.org>
Subject: [P4-design] Re: new language features for "5G" and "edge" use cases

Hi Nate,

Sorry for the long delay. I uploaded our example code here: https://github.com/P4ELTE/use_cases/tree/master/p4-16/bsthttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3Dff18bf44-a0838641-ff18ffdf-86959e472243-40dc13243106c319%26q%3D1%26e%3Dc06da983-d08b-4708-b883-00e45e68f49a%26u%3Dhttps%253A%252F%252Fnam04.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fgithub.com%25252FP4ELTE%25252Fuse_cases%25252Ftree%25252Fmaster%25252Fp4-16%25252Fbst%2526data%253D04%25257C01%25257Cmbudiu%252540vmware.com%25257Cce1277d5b5274442bcc508d9278f1647%25257Cb39138ca3cee4b4aa4d6cd83d9dd62f0%25257C0%25257C1%25257C637584317782235478%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253D2qbSNMuJ2vMGFQNJnN%25252FY17bZPd9ulONISn04VwBGavI%25253D%2526reserved%253D0&data=04%7C01%7Cmbudiu%40vmware.com%7Ccaaead125a664bdb711008d92c4138df%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637589480923435518%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Se8ejojWnQLdTgNIF%2B4dPYZAaUfxirBD%2F7kmbpjSmKE%3D&reserved=0
The main code is cpf_ran.p4. In theory it supports both TNA, PSA and V1 – we used Tofino’s compiler and t4p4s (basically p4c with DPDK backend) for compiling and running.

Buffering would be executed in the RANDownlink() control block, now we add a special header and send out the packet towards the service IP of the BaaS (buffer-as-a-service) which runs as a Kubernetes service for now. We could clone the packet just as well and send it directly to the downlink path while sending the copy to the buffer, but now it is sent to the buffer and on successful buffering the BaaS service returns the packet – this way we know that the original packet is buffered and timeout counter is started.

Regarding to your questions:

  1. You are right, maybe it could be solved by an extern similarly as we solve it with a non-P4 component. On the other hand I don’t particularly like having too much architectures around as that kills one of the main advantages of P4 (to my knowledge) which is portability. So I’d rather go for a language change with this – for me the only reason not doing that could be if the task would be impossible to support by some hardware targets. You know the language much better, but I’d say buffering a few packets could be similar to having a bit more registers. So buffering itself doesn’t seem a huge issue for me. Running timers and assigning events to them on the other hand might be a bigger change as potentially there would be a large amount of parallel timers – and of course there are good data structures for that, but are they hardware friendly enough? Ibanez’s presentation suggests it can be done fairly simply on FPGA.
  2. According to the presentation I think the proposed solution – especially if all proposed primitives on slide 6 would be implemented – is a superset of what we’d need (I’d say for us enqueue, dequeue and timer expiration would be enough). So if Ibanez’s proposal would be part of the language, we wouldn’t need more (at least for now).
  3. Yes, if you have a look at the code you’ll see that we already use control blocks for modularizing the code. With Tofino sometimes it’s not straightforward as the compiler tends to use more stages in this case compared to if you use less control blocks (this issue was also mentioned in the uP4 talk). As I understood, Lyra is a higher layer solution for portability over multiple DSLs, so I guess that would be handy if even in the long term portability would be an issue. I think Lyra’s composition part could deal with composing multiple modules / programs on a single switch – I guess you referred to this feature, but I don’t think we’d need a Lyra-like engine in the long run.

So my only question that is remaining: is the proposals from Ibanez & co. already considered by some of the working groups e.g. LDWG? If yes, I’ll go thru the details as that is quite likely a good solution for us too.
Thanks!

Gergely

Indeed, this should work. It currently does not, so I filed an issue: https://github.com/p4lang/p4c/issues/2795 Hopefully this (and support in your favorite back-end) is everything that is needed. If not, we’ll file more issues. Mihai From: Gurevich, Vladimir <vladimir.gurevich@intel.com> Sent: Thursday, June 10, 2021 11:55 AM To: Mihai Budiu <mbudiu@vmware.com>; Gergely Pongracz <Gergely.Pongracz@ericsson.com>; hemant@mnkcg.com; jnfoster@cs.cornell.edu Cc: p4-design@lists.p4.org Subject: Re: [P4-design] Re: new language features for "5G" and "edge" use cases Hello Mihai, So far, I am a little hesitant to allow pkt.emit() for the scalar types, mostly because I do not have a good proposal on how to handle non-byte-aligned ones. I wonder, whether a construct like: pkt.emit((bridge_t){f1, f2}); will do the job of an unconditional emit, since we are effectively creating a valid header on the spot, so the compiler will be free to optimize the validity check out. At the same time, the byte alignment requirement can still be enforced. Thanks, Vladimir Gurevich Principal Engineer, Barefoot Division (BXD)<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fintel.com%2Fprogrammable-networking&data=04%7C01%7Cmbudiu%40vmware.com%7Ccaaead125a664bdb711008d92c4138df%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637589480923395539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UsE5phakl2ecAsSkh0BAZUU7fTAuQpwpzKrNOChcph8%3D&reserved=0> Director, Intel® Connectivity Education Hub<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fintel.com%2Fconnectivity-education&data=04%7C01%7Cmbudiu%40vmware.com%7Ccaaead125a664bdb711008d92c4138df%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637589480923405640%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GGyNepNxDOPuAIhm5OOZ7NSCmjeZR1GRbvFxa80y%2Bs8%3D&reserved=0> Email: Vladimir.Gurevich@intel.com<mailto:Vladimir.Gurevich@intel.com> Cell: +1 (408) 833-4505 [A close up of a sign Description automatically generated]<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fintel.com%2F&data=04%7C01%7Cmbudiu%40vmware.com%7Ccaaead125a664bdb711008d92c4138df%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637589480923405640%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4qZX%2Byz4l8ygWgxNtp0q0hD1hB4hVGHNc5cnFDlkxCc%3D&reserved=0> From: Mihai Budiu <mbudiu@vmware.com<mailto:mbudiu@vmware.com>> Date: Monday, June 7, 2021 at 8:55 PM To: "Gurevich, Vladimir" <vladimir.gurevich@intel.com<mailto:vladimir.gurevich@intel.com>>, Gergely Pongracz <Gergely.Pongracz@ericsson.com<mailto:Gergely.Pongracz@ericsson.com>>, "hemant@mnkcg.com<mailto:hemant@mnkcg.com>" <hemant@mnkcg.com<mailto:hemant@mnkcg.com>>, "jnfoster@cs.cornell.edu<mailto:jnfoster@cs.cornell.edu>" <jnfoster@cs.cornell.edu<mailto:jnfoster@cs.cornell.edu>> Cc: "p4-design@lists.p4.org<mailto:p4-design@lists.p4.org>" <p4-design@lists.p4.org<mailto:p4-design@lists.p4.org>> Subject: RE: [P4-design] Re: new language features for "5G" and "edge" use cases Section 15.1 of the spec says: * It is illegal to invoke emit on an expression whose type is a base type, enum, or error. If we had emit for base types this could work very well. I see no problem why that would not work. If that’s what you want you should file an issue with the spec so we can discuss this during the design meeting. You don’t need a new method, the existing emit should work just fine. Mihai From: Gurevich, Vladimir <vladimir.gurevich@intel.com<mailto:vladimir.gurevich@intel.com>> Sent: Monday, June 7, 2021 6:27 AM To: Gergely Pongracz <Gergely.Pongracz@ericsson.com<mailto:Gergely.Pongracz@ericsson.com>>; hemant@mnkcg.com<mailto:hemant@mnkcg.com>; Mihai Budiu <mbudiu@vmware.com<mailto:mbudiu@vmware.com>>; jnfoster@cs.cornell.edu<mailto:jnfoster@cs.cornell.edu> Cc: p4-design@lists.p4.org<mailto:p4-design@lists.p4.org> Subject: Re: [P4-design] Re: new language features for "5G" and "edge" use cases All, To be honest, I think that what be more useful is to have an unconditional emit 😊. Aside from the fact that it will, obviously allow us to express the traditional emit as: pkt.emit(hdr.a) ::= if (hdr.a.isValid()) { pkt.unconditional_emit(hdr.a); } it would also allow us to be more flexible with other emits and allow us to optimize the programs on certain architectures. As a practical example, it is quite helpful when someone needs to create a bridge header in PSA, TNA or a similar architecture “on the fly”, e.g: header bridge_h { type1_t f1; /* Usually comes from meta.f1 */ type2_t f2; /* Usually comes from meta.f2 */ } struct my_headers_t { ethernet_h ethernet; . . . . } control IgressDeparser( packet_out pkt, my_headers_t hdr, my_meta_t meta) { /* Emit on the fly and there is no need to keep the header validity bit around */ pkt.uncoditional_emit<bridge_h>(meta.f1, meta.f2); pkt.emit(hdr); } Currently we have to make the header valid and copy the data into it (typically at the end of the control) and while the compiler can optimize many of these assignments and such, it is always better when someone can clearly express the intent. Again, it is not that a big deal (it is possible to live without this), but I thought it will make the overall design more orthogonal. The name “unconditional_emit()” is certainly not the prettiest one – I put it here for clarity only. Best, Vladimir Gurevich Principal Engineer, Barefoot Division (BXD)<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fintel.com%2Fprogrammable-networking&data=04%7C01%7Cmbudiu%40vmware.com%7Ccaaead125a664bdb711008d92c4138df%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637589480923405640%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NqImAD3PW5bnW2uXZIOxbGzgeK5rz6i%2FUBosZ4vluvY%3D&reserved=0> Director, Intel® Connectivity Education Hub<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fintel.com%2Fconnectivity-education&data=04%7C01%7Cmbudiu%40vmware.com%7Ccaaead125a664bdb711008d92c4138df%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637589480923415528%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QURa%2BcbNGVuSNs%2Fm42QalrMjdPbn5eiB4h1Vpy%2BUwV4%3D&reserved=0> Email: Vladimir.Gurevich@intel.com<mailto:Vladimir.Gurevich@intel.com> Cell: +1 (408) 833-4505 [A close up of a sign Description automatically generated]<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fintel.com%2F&data=04%7C01%7Cmbudiu%40vmware.com%7Ccaaead125a664bdb711008d92c4138df%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637589480923425524%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hR7dQNw3HrUM62IAUXsOalWTxR6%2FiPqOtM8uldgR8eI%3D&reserved=0> From: Gergely Pongracz via P4-design <p4-design@lists.p4.org<mailto:p4-design@lists.p4.org>> Reply-To: Gergely Pongracz <Gergely.Pongracz@ericsson.com<mailto:Gergely.Pongracz@ericsson.com>> Date: Monday, June 7, 2021 at 12:30 PM To: "hemant@mnkcg.com<mailto:hemant@mnkcg.com>" <hemant@mnkcg.com<mailto:hemant@mnkcg.com>>, "mbudiu@vmware.com<mailto:mbudiu@vmware.com>" <mbudiu@vmware.com<mailto:mbudiu@vmware.com>>, "jnfoster@cs.cornell.edu<mailto:jnfoster@cs.cornell.edu>" <jnfoster@cs.cornell.edu<mailto:jnfoster@cs.cornell.edu>> Cc: "p4-design@lists.p4.org<mailto:p4-design@lists.p4.org>" <p4-design@lists.p4.org<mailto:p4-design@lists.p4.org>> Subject: [P4-design] Re: new language features for "5G" and "edge" use cases Hi, Guys, don’t get stuck on this, as I indicated in the paper this is a minor issue, we solved it exactly as Mihai proposed below. BR, Gergely From: hemant@mnkcg.com<mailto:hemant@mnkcg.com> <hemant@mnkcg.com<mailto:hemant@mnkcg.com>> Sent: Friday, June 4, 2021 10:54 PM To: mbudiu@vmware.com<mailto:mbudiu@vmware.com>; Gergely Pongracz <Gergely.Pongracz@ericsson.com<mailto:Gergely.Pongracz@ericsson.com>>; jnfoster@cs.cornell.edu<mailto:jnfoster@cs.cornell.edu> Cc: p4-design@lists.p4.org<mailto:p4-design@lists.p4.org> Subject: RE: [P4-design] Re: new language features for "5G" and "edge" use cases Mihai, I was only echoing the ask from Gergely slides. Indeed, I too have written code such that I used the if-condition in egress control and set a header to invalid. So, I don’t see a pressing need to use if condition in deparser. Hemant From: Mihai Budiu <mbudiu@vmware.com<mailto:mbudiu@vmware.com>> Sent: Friday, June 04, 2021 4:49 PM To: hemant@mnkcg.com<mailto:hemant@mnkcg.com>; Gergely.Pongracz@ericsson.com<mailto:Gergely.Pongracz@ericsson.com>; jnfoster@cs.cornell.edu<mailto:jnfoster@cs.cornell.edu> Subject: RE: [P4-design] Re: new language features for "5G" and "edge" use cases First, please note that P4 does not limit deparser to just emit statements; a deparser is a general control, and it can certainly have if statements. Only *targets* (i.e., backends) may limit what the deparser can do. I will submit a PR against the p4c-xdp target to show that this is supported by P4. Second, for architectures like Tofino, a statement like this in the deparser: If (condition) packet.emit(h); Can be rewritten as two statements: 1. In egress, towards the end: if (!condition) h.setInvalid(); 1. And in deparser an unconditional emit: packet.emit(h); For a specific architecture we could even make this transformation automatically. Mihai From: hemant@mnkcg.com<mailto:hemant@mnkcg.com> <hemant@mnkcg.com<mailto:hemant@mnkcg.com>> Sent: Friday, June 4, 2021 1:18 PM To: Mihai Budiu <mbudiu@vmware.com<mailto:mbudiu@vmware.com>>; Gergely.Pongracz@ericsson.com<mailto:Gergely.Pongracz@ericsson.com>; jnfoster@cs.cornell.edu<mailto:jnfoster@cs.cornell.edu> Subject: RE: [P4-design] Re: new language features for "5G" and "edge" use cases I understand, an invalid header is not emitted. However, what if I want an if-condition such as if (bla-bla), then emit a header. Thanks, Hemant From: Mihai Budiu <mbudiu@vmware.com<mailto:mbudiu@vmware.com>> Sent: Friday, June 04, 2021 4:02 PM To: hemant@mnkcg.com<mailto:hemant@mnkcg.com>; Gergely.Pongracz@ericsson.com<mailto:Gergely.Pongracz@ericsson.com>; jnfoster@cs.cornell.edu<mailto:jnfoster@cs.cornell.edu> Subject: RE: [P4-design] Re: new language features for "5G" and "edge" use cases Why is a conditional emit necessary? Invalid headers are not emitted. Mihai From: Hemant Singh via P4-design <p4-design@lists.p4.org<mailto:p4-design@lists.p4.org>> Sent: Friday, June 4, 2021 12:30 PM To: Gergely.Pongracz@ericsson.com<mailto:Gergely.Pongracz@ericsson.com>; jnfoster@cs.cornell.edu<mailto:jnfoster@cs.cornell.edu> Cc: p4-design@lists.p4.org<mailto:p4-design@lists.p4.org> Subject: [P4-design] Re: new language features for "5G" and "edge" use cases If one sees Gergely’s slides (https://opennetworking.org/wp-content/uploads/2021/05/Gergely-Pongracz-Slides.pdf<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D1624152c-49bf2c29-162455b7-86959e472243-22c1e57e660a62c9%26q%3D1%26e%3Dc06da983-d08b-4708-b883-00e45e68f49a%26u%3Dhttps%253A%252F%252Fnam04.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fopennetworking.org%25252Fwp-content%25252Fuploads%25252F2021%25252F05%25252FGergely-Pongracz-Slides.pdf%2526data%253D04%25257C01%25257Cmbudiu%252540vmware.com%25257Cce1277d5b5274442bcc508d9278f1647%25257Cb39138ca3cee4b4aa4d6cd83d9dd62f0%25257C0%25257C1%25257C637584317782230493%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253DVzYSSFY3cpIbHogO%25252Fy1ovMCwdxkxwQi%25252FA%25252FA%25252BcSvLoY0%25253D%2526reserved%253D0&data=04%7C01%7Cmbudiu%40vmware.com%7Ccaaead125a664bdb711008d92c4138df%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637589480923425524%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8O4yKPcbV1GDvzjgpEidtrRrKIf7p9vpJgsMBnrI09Q%3D&reserved=0>), he has also asked for conditional emit in deparser. p4c has already added an if condition to the P4 parser during this year. We should discuss use of conditional in deparser, at least for certain low speed architectures. Thanks, Hemant From: Gergely Pongracz via P4-design <p4-design@lists.p4.org<mailto:p4-design@lists.p4.org>> Sent: Friday, June 04, 2021 5:14 AM To: Nate Foster <jnfoster@cs.cornell.edu<mailto:jnfoster@cs.cornell.edu>> Cc: p4-design <p4-design@lists.p4.org<mailto:p4-design@lists.p4.org>> Subject: [P4-design] Re: new language features for "5G" and "edge" use cases Hi Nate, Sorry for the long delay. I uploaded our example code here: https://github.com/P4ELTE/use_cases/tree/master/p4-16/bst<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3Dff18bf44-a0838641-ff18ffdf-86959e472243-40dc13243106c319%26q%3D1%26e%3Dc06da983-d08b-4708-b883-00e45e68f49a%26u%3Dhttps%253A%252F%252Fnam04.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fgithub.com%25252FP4ELTE%25252Fuse_cases%25252Ftree%25252Fmaster%25252Fp4-16%25252Fbst%2526data%253D04%25257C01%25257Cmbudiu%252540vmware.com%25257Cce1277d5b5274442bcc508d9278f1647%25257Cb39138ca3cee4b4aa4d6cd83d9dd62f0%25257C0%25257C1%25257C637584317782235478%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253D2qbSNMuJ2vMGFQNJnN%25252FY17bZPd9ulONISn04VwBGavI%25253D%2526reserved%253D0&data=04%7C01%7Cmbudiu%40vmware.com%7Ccaaead125a664bdb711008d92c4138df%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637589480923435518%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Se8ejojWnQLdTgNIF%2B4dPYZAaUfxirBD%2F7kmbpjSmKE%3D&reserved=0> The main code is cpf_ran.p4. In theory it supports both TNA, PSA and V1 – we used Tofino’s compiler and t4p4s (basically p4c with DPDK backend) for compiling and running. Buffering would be executed in the RANDownlink() control block, now we add a special header and send out the packet towards the service IP of the BaaS (buffer-as-a-service) which runs as a Kubernetes service for now. We could clone the packet just as well and send it directly to the downlink path while sending the copy to the buffer, but now it is sent to the buffer and on successful buffering the BaaS service returns the packet – this way we know that the original packet is buffered and timeout counter is started. Regarding to your questions: 1. You are right, maybe it could be solved by an extern similarly as we solve it with a non-P4 component. On the other hand I don’t particularly like having too much architectures around as that kills one of the main advantages of P4 (to my knowledge) which is portability. So I’d rather go for a language change with this – for me the only reason not doing that could be if the task would be impossible to support by some hardware targets. You know the language much better, but I’d say buffering a few packets could be similar to having a bit more registers. So buffering itself doesn’t seem a huge issue for me. Running timers and assigning events to them on the other hand might be a bigger change as potentially there would be a large amount of parallel timers – and of course there are good data structures for that, but are they hardware friendly enough? Ibanez’s presentation suggests it can be done fairly simply on FPGA. 2. According to the presentation I think the proposed solution – especially if all proposed primitives on slide 6 would be implemented – is a superset of what we’d need (I’d say for us enqueue, dequeue and timer expiration would be enough). So if Ibanez’s proposal would be part of the language, we wouldn’t need more (at least for now). 3. Yes, if you have a look at the code you’ll see that we already use control blocks for modularizing the code. With Tofino sometimes it’s not straightforward as the compiler tends to use more stages in this case compared to if you use less control blocks (this issue was also mentioned in the uP4 talk). As I understood, Lyra is a higher layer solution for portability over multiple DSLs, so I guess that would be handy if even in the long term portability would be an issue. I think Lyra’s composition part could deal with composing multiple modules / programs on a single switch – I guess you referred to this feature, but I don’t think we’d need a Lyra-like engine in the long run. So my only question that is remaining: is the proposals from Ibanez & co. already considered by some of the working groups e.g. LDWG? If yes, I’ll go thru the details as that is quite likely a good solution for us too. Thanks! Gergely