| Message ID | 20170615233649.10914-1-joe@ovn.org |
|---|---|
| State | Accepted |
| Headers | show |
On 15 June 2017 at 16:36, Joe Stringer <joe@ovn.org> wrote: > Currently, the set of flows that may be offloaded is very small compared > to the overall capabilities of the OpenFlow support in OVS. In the > majority of cases, if a user attempts to enable this flag they are > unlikely to observe a performance increase, because for instance they > lack the correct hardware; lack the correct kernel version; or their > flow tables are too complex for the hardware to handle. > > To moderate expectations around this feature, describe it as > experimental. Over time, we expect that the functionality and usefulness > of this feature will grow and we should be in a better shape to revisit > the status of this functionality after it has had some time to mature. > > Signed-off-by: Joe Stringer <joe@ovn.org> > --- Hi folks, this is a pretty high level description of some of the limitations. I wonder if we could add another table to the FAQ underneath the question "Are all features available with all datapaths?" to answer the questions "Which features can be offloaded to hardware?" and "Which hardware supports hardware offload"? It seems to me like minimum to configure this stuff is 4.2, but various fields are still being added to the matching side of this... then only a small subset of actions can be offloaded.. then there's the question of which kernels began to distribute drivers with support to offload to particular NICs and switches. Could someone take a stab at documenting this for users?
On Thu, Jun 15, 2017 at 04:36:49PM -0700, Joe Stringer wrote: > Currently, the set of flows that may be offloaded is very small compared > to the overall capabilities of the OpenFlow support in OVS. In the > majority of cases, if a user attempts to enable this flag they are > unlikely to observe a performance increase, because for instance they > lack the correct hardware; lack the correct kernel version; or their > flow tables are too complex for the hardware to handle. > > To moderate expectations around this feature, describe it as > experimental. Over time, we expect that the functionality and usefulness > of this feature will grow and we should be in a better shape to revisit > the status of this functionality after it has had some time to mature. > > Signed-off-by: Joe Stringer <joe@ovn.org> Acked-by: Simon Horman <simon.horman@netronome.com>
On Thu, Jun 15, 2017 at 04:36:49PM -0700, Joe Stringer wrote: > Currently, the set of flows that may be offloaded is very small compared > to the overall capabilities of the OpenFlow support in OVS. In the > majority of cases, if a user attempts to enable this flag they are > unlikely to observe a performance increase, because for instance they > lack the correct hardware; lack the correct kernel version; or their > flow tables are too complex for the hardware to handle. > > To moderate expectations around this feature, describe it as > experimental. Over time, we expect that the functionality and usefulness > of this feature will grow and we should be in a better shape to revisit > the status of this functionality after it has had some time to mature. > > Signed-off-by: Joe Stringer <joe@ovn.org> > --- Thanks for following up with this Joe. Acked-by: Flavio Leitner <fbl@sysclose.org>
On 19 June 2017 at 05:26, Flavio Leitner <fbl@sysclose.org> wrote: > On Thu, Jun 15, 2017 at 04:36:49PM -0700, Joe Stringer wrote: >> Currently, the set of flows that may be offloaded is very small compared >> to the overall capabilities of the OpenFlow support in OVS. In the >> majority of cases, if a user attempts to enable this flag they are >> unlikely to observe a performance increase, because for instance they >> lack the correct hardware; lack the correct kernel version; or their >> flow tables are too complex for the hardware to handle. >> >> To moderate expectations around this feature, describe it as >> experimental. Over time, we expect that the functionality and usefulness >> of this feature will grow and we should be in a better shape to revisit >> the status of this functionality after it has had some time to mature. >> >> Signed-off-by: Joe Stringer <joe@ovn.org> >> --- > > Thanks for following up with this Joe. > > Acked-by: Flavio Leitner <fbl@sysclose.org> Thanks for the review, applied to master.
diff --git a/NEWS b/NEWS index a2f5a6dc8e54..4ea7e628e1fc 100644 --- a/NEWS +++ b/NEWS @@ -65,7 +65,7 @@ Post-v2.7.0 * Transparently pop and push Ethernet headers at transmit/reception of packets to/from L3 tunnels. - The BFD detection multiplier is now user-configurable. - - New support for HW offloading + - Add experimental support for hardware offloading * HW offloading is disabled by default. * HW offloading is done through the TC interface. diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml index 9bb828faa8eb..500f05a24280 100644 --- a/vswitchd/vswitch.xml +++ b/vswitchd/vswitch.xml @@ -192,6 +192,11 @@ <p> Currently Open vSwitch supports hardware offloading on Linux systems. On other systems, this value is ignored. + This functionality is considered 'experimental'. Depending + on which OpenFlow matches and actions are configured, + which kernel version is used, and what hardware is + available, Open vSwitch may not be able to offload + functionality to hardware. </p> </column>
Currently, the set of flows that may be offloaded is very small compared to the overall capabilities of the OpenFlow support in OVS. In the majority of cases, if a user attempts to enable this flag they are unlikely to observe a performance increase, because for instance they lack the correct hardware; lack the correct kernel version; or their flow tables are too complex for the hardware to handle. To moderate expectations around this feature, describe it as experimental. Over time, we expect that the functionality and usefulness of this feature will grow and we should be in a better shape to revisit the status of this functionality after it has had some time to mature. Signed-off-by: Joe Stringer <joe@ovn.org> --- CC: Paul Blakey <paulb@mellanox.com> CC: Roi Dayan <roid@mellanox.com> CC: Simon Horman <simon.horman@netronome.com> CC: Flavio Leitner <fbl@sysclose.org> --- NEWS | 2 +- vswitchd/vswitch.xml | 5 +++++ 2 files changed, 6 insertions(+), 1 deletion(-)