Choi et al. propose PISCES which is compiler for a software switch which allows custom protocol specifications in a high level domain specific language (DSL) and compiles it to a actual C code.
Choi starts with highlighting the importance of programmability of forwarding behaviour. He starts with providing context using hardware switching. There is a current push towards making programmable hardware chips, similarly, if you look at the current day data centers we see that the switching is mostly done in software to achieve high degree of programmability.
Choi argues that while software switches are great in terms of performing quick updates than a hardware switch, implementing new features in the software switch still requires deep knowledge of the hypervisor kernel that most network operators may not have. Additionally, changes to the switching not only need to implemented but maintained over time which imposes a significant management burden. This complexity is not suitable for altering the forwarding behaviour of a switch and we need mechanisms to make this task easier for network operators.
Towards this end, the team proposes their compiler called PISCES which takes forwarding behaviour of a switch described in a domain specific language (P4) and compiles to a target switch level C code. They show that code compiled from PISCES approaches the performance of hand-written code while reducing the program size by 40%.
The platform chosen by the team for their prototype is OVS (Open vSwitch) in which they replace the parse, match, action code by the code generated by their PISCES compiler. In order to swap in the new OVS configuration, it simply requires a reboot of the switch and then entire process takes between 20-30 seconds. In order to make OVS amenable to programs specified in P4, they make three key changes to OVS. These include the ability to perform arbitrary encapsulation/decapsulation through post-pipeline and inline editing modes, the ability to perform actions based on conditional statements and the ability to compute checksums incrementally.
They evaluate the performance of PISCES on accounts of complexity of describing a baseline for a switch and the complexity of making changes to switch compared to OVS code. The results show that the number of lines of code needed to build a baseline for a switch is two orders of magnitude smaller than the OVS implementation and making changes requires modifications of less than 10 lines for a number of use cases.
They also compare the forwarding performance of the switch compared to hand-coded OVS switch, the results show that with compiler optimizations, the performance of PISCES is within 2% of the OVS switch over a range of packet sizes.
In summary PISCES allows quick development and maintenance of OVS switch with very low overhead.
The following questions were put forth after the talk:
Q: What happens when you need a functionality when it is not in the OVS? like rate-limiting.
A: We also implement the P4 primitives, so if you need action on P4 primitives those are also supported in our work.
Q: Have you tried a different target switch than OVS?
A: We are trying different switches such as switches from Cisco and Barefoot's implementation of the software switch. We choose OVS because its forwarding model is close to P4.
Q: Have you done full implementation of the specification of P4, if not then why?
A: We implemented all except varying packets sizes and stateful processing. We weren't able to do a one to one mapping for stateful processing.
Choi starts with highlighting the importance of programmability of forwarding behaviour. He starts with providing context using hardware switching. There is a current push towards making programmable hardware chips, similarly, if you look at the current day data centers we see that the switching is mostly done in software to achieve high degree of programmability.
Choi argues that while software switches are great in terms of performing quick updates than a hardware switch, implementing new features in the software switch still requires deep knowledge of the hypervisor kernel that most network operators may not have. Additionally, changes to the switching not only need to implemented but maintained over time which imposes a significant management burden. This complexity is not suitable for altering the forwarding behaviour of a switch and we need mechanisms to make this task easier for network operators.
Towards this end, the team proposes their compiler called PISCES which takes forwarding behaviour of a switch described in a domain specific language (P4) and compiles to a target switch level C code. They show that code compiled from PISCES approaches the performance of hand-written code while reducing the program size by 40%.
The platform chosen by the team for their prototype is OVS (Open vSwitch) in which they replace the parse, match, action code by the code generated by their PISCES compiler. In order to swap in the new OVS configuration, it simply requires a reboot of the switch and then entire process takes between 20-30 seconds. In order to make OVS amenable to programs specified in P4, they make three key changes to OVS. These include the ability to perform arbitrary encapsulation/decapsulation through post-pipeline and inline editing modes, the ability to perform actions based on conditional statements and the ability to compute checksums incrementally.
They evaluate the performance of PISCES on accounts of complexity of describing a baseline for a switch and the complexity of making changes to switch compared to OVS code. The results show that the number of lines of code needed to build a baseline for a switch is two orders of magnitude smaller than the OVS implementation and making changes requires modifications of less than 10 lines for a number of use cases.
They also compare the forwarding performance of the switch compared to hand-coded OVS switch, the results show that with compiler optimizations, the performance of PISCES is within 2% of the OVS switch over a range of packet sizes.
In summary PISCES allows quick development and maintenance of OVS switch with very low overhead.
The following questions were put forth after the talk:
Q: What happens when you need a functionality when it is not in the OVS? like rate-limiting.
A: We also implement the P4 primitives, so if you need action on P4 primitives those are also supported in our work.
Q: Have you tried a different target switch than OVS?
A: We are trying different switches such as switches from Cisco and Barefoot's implementation of the software switch. We choose OVS because its forwarding model is close to P4.
Q: Have you done full implementation of the specification of P4, if not then why?
A: We implemented all except varying packets sizes and stateful processing. We weren't able to do a one to one mapping for stateful processing.
No comments:
Post a Comment