Hi,
Cloud workloads today require extremely high bandwidth and low latency.
These high-performance demands make it essential for OVS to leverage
hardware acceleration with specialized hardware to maintain scalability,
reduce CPU load, and ensure efficient processing at speeds at rates of
hundreds of gigabits per second. That is for OVS to still remain competitive
in those environments.
There have been attempts to add hardware acceleration for both OVS kernel
version and OVS DPDK. In both cases, while some acceleration has been
achieved, the real potential for performance improvements is hindered by
architectural constraints. These constraints primarily arise because the
hardware acceleration interface is logically positioned "below" the data
path, meaning the data path structure dictates the acceleration.
It seems that treating hardware acceleration as an independent data path,
and allowing vendors to fully implement their own solutions, will unlock
the true value of acceleration. The accelerated data path implementation
should not be dictated by specific technologies like RTE_FLOW or P4 but
should be open to any implementation.
We lack the place were each vendor can freely create its own hardware model.
Currently, the hardware model is build based on limited information that
is propagated to netdev offload, lacking any information about the
packet’s flow, therefore is sub optimal.
Not every hardware offload optimization in the DPIF-netdev layer will
benefit the software implementation, and in some cases it can be the
contrary. Therefore we want to have a DPIF that is mainly focused on
hardware data-plane where we can fully optimize it for that use-case.
A new netdev-offload requires a new type of netdev. This is not good since
we want to support our own hardware model with existing netdevs as well.
Also in this approach we are still missing the packet context that can be
useful for optimizations.
The proposal is to make the dpif interface a pluggable API that can be loaded
at runtime. Each vendor would be free to implement their version and provide
it as a shared object that can be loaded at runtime. Vendors can then create
a hardware-accelerated OVS that fully integrates with the OVS ecosystem and
control system.
The following series demonstrates an api for a pluggable dpif where each
vendor could implement its own dpif outside the openvswitch repository.
Limitations are, once DPIFs are implemented outside of the OVS repository
there is a need to maintain some sort of compatability for the dpif_class API.
Possible solution could be versioning not to load DPIF with lower version,
add some runtime checks in the dpif and always make sure class changes
are done with backwards compatibility in mind.
The series show an example of dpif-netdev to be pluggable and thus
updating api like dpif_is_netdev to a dpif_class api to avoid
direct connection between dpif and dpif_class.
The compilation needs to be done as shared. The compilation command I used is
as the following:
CFLAGS="-O0 -g3" ./configure --prefix=/usr --localstatedir=/var \
--sysconfdir=/etc --with-dpdk=shared --enable-Werror \
--enable-shared && make -j22 -s
Thanks,
Roi
Roi Dayan (8):
dpif-plugin: Add pluggable dpif api
dpif-plugin: add bridge_init api
dpif-netdev: Move dpif into a plugin
dpif: Don't register buildtin netdev class
dpif: Move dpif_is_netdev into dpif.c as wrapper
dummy: Temporary disable dpif dummy registration
dpif-provider: Add dpif_class_version
dpif: Verify plugin dpif_class_version
build-aux/thread-safety-forbidden | 1 -
lib/automake.mk | 53 +++++++++++-------
lib/dpif-netdev.c | 21 +++++---
lib/dpif-netdev.h | 2 -
lib/dpif-netlink.c | 2 +
lib/dpif-plugin.c | 89 +++++++++++++++++++++++++++++++
lib/dpif-plugin.h | 41 ++++++++++++++
lib/dpif-provider.h | 14 +++++
lib/dpif.c | 33 +++++++++++-
lib/dummy.c | 2 +-
vswitchd/bridge.c | 2 +
11 files changed, 228 insertions(+), 32 deletions(-)
create mode 100644 lib/dpif-plugin.c
create mode 100644 lib/dpif-plugin.h
--
2.46.1
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
