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

H
hemant@mnkcg.com
Fri, Jun 4, 2021 8:53 PM

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
Sent: Friday, June 04, 2021 4:49 PM
To: hemant@mnkcg.com; Gergely.Pongracz@ericsson.com; 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-Slid
es.pdf
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopennetwo
rking.org%2Fwp-content%2Fuploads%2F2021%2F05%2FGergely-Pongracz-Slides.pdf&d
ata=04%7C01%7Cmbudiu%40vmware.com%7Cce1277d5b5274442bcc508d9278f1647%7Cb3913
8ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637584317782230493%7CUnknown%7CTWFpbGZ
sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30
00&sdata=VzYSSFY3cpIbHogO%2Fy1ovMCwdxkxwQi%2FA%2FA%2BcSvLoY0%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%2Fgithub.co
m%2FP4ELTE%2Fuse_cases%2Ftree%2Fmaster%2Fp4-16%2Fbst&data=04%7C01%7Cmbudiu%4
0vmware.com%7Cce1277d5b5274442bcc508d9278f1647%7Cb39138ca3cee4b4aa4d6cd83d9d
d62f0%7C0%7C1%7C637584317782235478%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2qbSNMuJ2vMGF
QNJnN%2FY17bZPd9ulONISn04VwBGavI%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

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> Sent: Friday, June 04, 2021 4:49 PM To: hemant@mnkcg.com; Gergely.Pongracz@ericsson.com; 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(); 2. 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-Slid es.pdf <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopennetwo rking.org%2Fwp-content%2Fuploads%2F2021%2F05%2FGergely-Pongracz-Slides.pdf&d ata=04%7C01%7Cmbudiu%40vmware.com%7Cce1277d5b5274442bcc508d9278f1647%7Cb3913 8ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637584317782230493%7CUnknown%7CTWFpbGZ sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30 00&sdata=VzYSSFY3cpIbHogO%2Fy1ovMCwdxkxwQi%2FA%2FA%2BcSvLoY0%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%2Fgithub.co m%2FP4ELTE%2Fuse_cases%2Ftree%2Fmaster%2Fp4-16%2Fbst&data=04%7C01%7Cmbudiu%4 0vmware.com%7Cce1277d5b5274442bcc508d9278f1647%7Cb39138ca3cee4b4aa4d6cd83d9d d62f0%7C0%7C1%7C637584317782235478%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2qbSNMuJ2vMGF QNJnN%2FY17bZPd9ulONISn04VwBGavI%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
GP
Gergely Pongracz
Mon, Jun 7, 2021 9:29 AM

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 hemant@mnkcg.com
Sent: Friday, June 4, 2021 10:54 PM
To: mbudiu@vmware.com; Gergely Pongracz Gergely.Pongracz@ericsson.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

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-Slid
es.pdf), 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

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

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 <hemant@mnkcg.com> Sent: Friday, June 4, 2021 10:54 PM To: mbudiu@vmware.com; Gergely Pongracz <Gergely.Pongracz@ericsson.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 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(); 2. 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-Slid es.pdf), 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 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
H
hemant@mnkcg.com
Mon, Jun 7, 2021 1:52 PM

Gergely,

Sounds good.  I filed two new issues against the use_cases code.  Please
look into the issues and get back.

https://github.com/P4ELTE/use_cases/issues/3

https://github.com/P4ELTE/use_cases/issues/2

I'd be happy to contribute to code changes since I have programmed the
Tofino and also bmv2 and ebpf p4c targets.

Thanks,

Hemant

From: Gergely Pongracz Gergely.Pongracz@ericsson.com
Sent: Monday, June 07, 2021 5:30 AM
To: hemant@mnkcg.com; mbudiu@vmware.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

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; 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-Slid
es.pdf), 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

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

Gergely, Sounds good. I filed two new issues against the use_cases code. Please look into the issues and get back. https://github.com/P4ELTE/use_cases/issues/3 https://github.com/P4ELTE/use_cases/issues/2 I'd be happy to contribute to code changes since I have programmed the Tofino and also bmv2 and ebpf p4c targets. Thanks, Hemant From: Gergely Pongracz <Gergely.Pongracz@ericsson.com> Sent: Monday, June 07, 2021 5:30 AM To: hemant@mnkcg.com; mbudiu@vmware.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 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; 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(); 2. 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-Slid es.pdf), 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 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