In this paper Gabor Retvari et al. present ESWITCH which takes as input forwarding behaviour of a switch in OpenFlow and compiles it to efficient code which can be run on the switch.
Retvari starts with the expressibility-performance tradeoff, he points out that while OpenFlow is great in terms of flexibility it provides in implementing rules at different packet layers, this genericity comes at the cost of performance. Specifically it is very hard to make OpenFlow perform better on x86 machines. This performance hit is due to the number of packet classification stages which need to be performed on the fast-path. The classification is needed to identify the packets belonging to a flow so that the corresponding actions for the flow can be performed. With the arrival of server virtualization in datacenters, these tasks now need to be performed on commodity x86 machines which do not have packet classification in hardware. In order to make up for this hardware support switches perform flow caching, however, the problem with flow caching is that it over-generalizes, since it enforces the same caching semantics over a set of diverse applications which run in a datacenter.
He argues that instead of having a general-purpose fast path we need to build mechanisms which allow the switch to automatically adapt and specialize itself for the workload type.
In order to attack this problem the team proposes ESWITCH which takes as input an OpenFlow pipeline and uses template code generation to output specialized code for a switch. ESWITCH is based on the insight that most OpenFlow pipelines combine only a small selection of simple but general primitives into complex dataplane programs. Therefore they can be reasonably represented using few templates where a template is a unit of a specific packet processing behaviour. ESWITCH is built upon the Intel DPDK and implements the packet parser template, matcher templates, flow table templates and action templates to provide the full set of forwarding functionality. It starts by deconstructing the OpenFlow input pipeline into basic packet processing primitives and matches the processing stages with the pre-built templates and then puts them together to build a pipeline.
For the evaluation, the team considers few use cases: layer 2 switching, layer 3 routing, a load balancer and telco access gateway. They conduct experiments over a range of traffic matrixes. For the first two use cases the results show that as the number of flows increases the performance of OVS with its flow caching goes down, ESWITCH on the other hand does not need to perform the flow caching and maintains high packet rates over a range of traffic mixes consistently reaching 12-14 Mbps, that is, within 1 Mbps of the benchmark (15Mbps). With respect to the latency, ESWITCH also maintains superiority over OVS as the number of active flows increase. He further shows the robustness of ESWITCH as the number updates per second increase.
In summary, for the switch to be truly programmable, the dataplane must also be programmable and this is exactly what the ESWITCH achieves.
The following questions were put forth after the talk:
Q: I was wondering if you have looked at specialization over different domains or have you compared in other domains?
A: OpenFlow is easy to specialize since it is well defined and there may be more domains where the idea of specialization can be generally applied but we haven't explored those yet.
Q: Do you generate the whole data plane after each update or is it just incremental?
A: Yes, we can update a templates incrementally, but for some templates such as the direct code template we need to compile it from scratch.
Q: The performance is great but it does go down with the number of flows, so at some stage it may not be enough, one idea is to offload the forwarding to other places in the network to accelerate under high pressure such as the vCRIB, but your work is putting more emphasis on the switch itself?
A: At the moment we haven't explored how this can be done with ESWITCH but we don't see why its fundamentally difficult with ESWITCH to achieve.
Retvari starts with the expressibility-performance tradeoff, he points out that while OpenFlow is great in terms of flexibility it provides in implementing rules at different packet layers, this genericity comes at the cost of performance. Specifically it is very hard to make OpenFlow perform better on x86 machines. This performance hit is due to the number of packet classification stages which need to be performed on the fast-path. The classification is needed to identify the packets belonging to a flow so that the corresponding actions for the flow can be performed. With the arrival of server virtualization in datacenters, these tasks now need to be performed on commodity x86 machines which do not have packet classification in hardware. In order to make up for this hardware support switches perform flow caching, however, the problem with flow caching is that it over-generalizes, since it enforces the same caching semantics over a set of diverse applications which run in a datacenter.
He argues that instead of having a general-purpose fast path we need to build mechanisms which allow the switch to automatically adapt and specialize itself for the workload type.
In order to attack this problem the team proposes ESWITCH which takes as input an OpenFlow pipeline and uses template code generation to output specialized code for a switch. ESWITCH is based on the insight that most OpenFlow pipelines combine only a small selection of simple but general primitives into complex dataplane programs. Therefore they can be reasonably represented using few templates where a template is a unit of a specific packet processing behaviour. ESWITCH is built upon the Intel DPDK and implements the packet parser template, matcher templates, flow table templates and action templates to provide the full set of forwarding functionality. It starts by deconstructing the OpenFlow input pipeline into basic packet processing primitives and matches the processing stages with the pre-built templates and then puts them together to build a pipeline.
For the evaluation, the team considers few use cases: layer 2 switching, layer 3 routing, a load balancer and telco access gateway. They conduct experiments over a range of traffic matrixes. For the first two use cases the results show that as the number of flows increases the performance of OVS with its flow caching goes down, ESWITCH on the other hand does not need to perform the flow caching and maintains high packet rates over a range of traffic mixes consistently reaching 12-14 Mbps, that is, within 1 Mbps of the benchmark (15Mbps). With respect to the latency, ESWITCH also maintains superiority over OVS as the number of active flows increase. He further shows the robustness of ESWITCH as the number updates per second increase.
In summary, for the switch to be truly programmable, the dataplane must also be programmable and this is exactly what the ESWITCH achieves.
The following questions were put forth after the talk:
Q: I was wondering if you have looked at specialization over different domains or have you compared in other domains?
A: OpenFlow is easy to specialize since it is well defined and there may be more domains where the idea of specialization can be generally applied but we haven't explored those yet.
Q: Do you generate the whole data plane after each update or is it just incremental?
A: Yes, we can update a templates incrementally, but for some templates such as the direct code template we need to compile it from scratch.
Q: The performance is great but it does go down with the number of flows, so at some stage it may not be enough, one idea is to offload the forwarding to other places in the network to accelerate under high pressure such as the vCRIB, but your work is putting more emphasis on the switch itself?
A: At the moment we haven't explored how this can be done with ESWITCH but we don't see why its fundamentally difficult with ESWITCH to achieve.
No comments:
Post a Comment