OVS rpc interface and ebpf refactor

[zasherif]

No description provided.

[zasherif]

We have shown OVS compatibility and support to run Mizar functional tests, this issue needs to address two parts:

Data-Plane:

This part shall provide code-refactoring to the exiting ebpf programs for a possibility to run in the OVS hook. This is primarily needed for deployment scenarios in which kernel update is impossible. I don't imagine serious production environments that should be reluctant to major kernel updates (at least from security updates perspectives), but we need this to be ready and proofed.

              |   +-------------------+
              |   |    ovs-vswitchd   |
              |   +-------------------+
    userspace |   |      ofproto      |<-->OpenFlow controllers
              |   +--------+-+--------+  
              |   | netdev | |ofproto-|
              |   +--------+ |  dpif  |
                  | netdev | +--------+
*eBPFhook new --> |provider| |  dpif  |
                  +---||---+ +--------+
              |       ||     |  dpif  | <--- *eBPF provider
              |       ||     |provider|
              |_      ||     +---||---+
                      ||         ||
               _  +---||-----+---||---+
              |   |          |datapath| <--- *eBPF datapath (**current**)
       kernel |   |          +--------+
              |   |                   |
              |_  +--------||---------+
                           ||
                        physical
                           NIC

Management-Plane:

Refactor/Rewrite the test controller workflows into the new micro-service based management plane in Mizar.

[HuaqingTu]

Hi, guys. I'm from USTC. Our group has some questions about establishing a fast path between the gateway node and OVS:

1. Does fast path mean that endpoints can communicate directly without passing through the gateway through tunnel technology? Or is packet forwarding in OVS kernel state?
2. In Mizar, if the endpoints of different subnets or VPCs communicate, the established direct path needs to go through the divider. Are we right? If so, when establishing a fast path between OVS and the gateway, whether the communication across the subnet and VPC must also pass through the gateway node?
3. We think that if we want to implement OVS fast path, we should change OVS source code. Is this acceptable?
4. Different versions of OVS have different source codes. Which version of OVS is used by the currently running cloud platform? Is the forwarding operation of OVS used by cloud platform based on OpenFlow protocol? If so, which version of OpenFlow is used?

Thanks for your help.

[zasherif]

Thank you for your questions and interest to contribute to Mizar:

1. We have two things: fast-path (in-kernel), and direct-path (no middle-gateway on the overlay level). Sometimes we use direct-path and fast-path interchangeably. This link describes current direct path design and implementation with XDP: https://mizar.readthedocs.io/en/latest/design/dp_direct_path/.
2. Yes in case of cross-network traffic, packets must go through the divider otherwise we cannot evaluate ACL correctly.
3. The answer depends on what exactly are you going to change. Being acceptable or not is something to be evaluated by the OVS community. The proposal in this issue is to use the OVS/ebpf version and find a way to install flow-rules based on Geneve RTS options in the packet.
4. You can use any version you like here in Mizar, just tell us why did you make that choice. You can also use Openflow (any version you want), as long as you show it has no performance impact.

I would recommend starting first by evaluating the ovs/ebpf approach, because it may be the least intrusive and allow reuse of existing Mizar code: https://github.com/williamtu/ovs-ebpf

[deepak-vij]

We think that if we want to implement OVS fast path, we should change OVS source code. Is this acceptable?

Shouldn't we use "Mizar OVS Adapter" approach versus changing the OVS itself. Essentially, "Mizar OVS Adapter" configures the flow rules in order to facilitate fastpath for OVS.

Similar adapter could be built for virtual networking solutions such as Tungsten Fabric (MPLS/BGP based) and so on.

[zasherif]

Both open-flow or ebpf based approaches are considered a form of an adapter with no (or minimal) change on the OVS side. I don't want to discourage @HuaqingTu from exploring proposed changes to OVS as well if that makes sense because packet exiting the data-path for userspace is a slow-path. Fortunately, we don't need to worry much about these with XDP/ebpf because all the packet processing is running in the Kernel anyway!!

[zhangml]

Hello, what are the main advantages of "Mizar OVS Adapter" compared to "OVS with DPDK"? How big is the difference in forwarding efficiency between the two?

[zasherif]

Well, the adapter and ovs-dpdk are two separate topics. The adapter role is to understand the "Direct path" protocol in Mizar and program OVS accordingly. Using ovs-ebpf, ovs-dpdk, ovs-xdp, OpenFlow, or modify ovs data-paths is an implementation-specific that needs to justify the performance of each approach. Does that make sense?